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Abstract 


Life-critical applications warrant a higher level of software reliability than has yet 
been achieved. Since it is not certain that traditional methods alone can provide 
the required ultra-reliability, new methods should be examined as supplements or 
replacements. This paper describes a mathematical counterpart to the traditional 
process of empirical testing. 

ORA’s Penelope verification system is demonstrated as a tool for evaluating the 
correctness of Ada software. Grady Booch’s Ada calendar utility package, obtained 
through NASA, was specified in the Larch/Ada language. Formal verification in the 
Penelope environment established that many of the package’s subprograms met their 
specifications. In other subprograms, failed attempts at verification revealed several 
errors that had escaped detection by testing. 

Keywords 

Life-critical software, ultra-reliability, formal methods, formal specification, 
formal verification, safety 
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Preface 


This report provides computer science professionals with a demonstration of 
Penelope, ORA’s program verification system for producing highly reliable Ada 
components. The reader familiar with the Ada language will find the document 
self-explanatory. No prior knowledge is required of program verification in gen- 
eral or Penelope in particular: the basic concepts of program verification are 
explained before they are applied. 

From this document, the reader should obtain a basic understanding of the 
capabilities and methods of the Penelope system when used as a counterpart 
to testing. The reader should also see that evaluating completed software is 
only one of many possible applications of program verification. The reader 
who wishes to explore the possibilities is directed to the suggestions for further 
reading. 


vii 




Summary 

Ultra-reliable software for life-critical aerospace applications is NASA’s goal. 
Specifically, the FAA proposes a probability of 10 -9 of catastrophic failure dur- 
ing one service hour. Conventional software development methods have not by 
themselves produced ultra-reliable software. Several fly-by- wire systems now 
in service have failed catastrophically. Improvements to conventional methods 
need to be investigated. Promising alternative approaches deserve examination 
as well. Formal verification applies the power and precision of mathematics 
to the development of life-critical software, in such a way that software can 
be unambiguously specified and conclusively proved to meet its specifications. 
ORA has developed Penelope, a computerized system for formally verifying Ada 
software. This report demonstrates Penelope’s capabilities. 

NASA provided ORA with Grady Booch’s Calendar-Utilities, a commer- 
cially released utility package, suitable for navigational uses. The package fea- 
tures several convenient representations of time and date and manipulations of 
them. ORA formally specified Calendar -Utilities using the Larch/ Ada math- 
ematical specification language. ORA formally verified Calendar-Utilities 
using the Penelope verification environment. 

Formal specification provided an unambiguous description of every subpro- 
gram in the package. Informal analysis then uncovered dubious software and 
three outright errors. Formal verification determined the status of eleven repre- 
sentative subprograms. Successful proofs demonstrated nine subprograms to be 
correct. In two subprograms, failed attempts at verifications revealed additional 
errors in human blind spots. 

Penelope is an effective, prototype tool which holds promise for producing 
ultra-reliable Ada software. As ORA continues development, Penelope will be- 
come even more effective. 
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1 Introduction 

As the complexity of life-critical computer applications increases and the reliance 
placed upon these applications grows, software developers will have to attain 
higher levels of reliability than have been possible to date. Since it cannot be 
foreseen whether today’s software practices will scale up to meet the challenge, 
alternative approaches need to be examined. One promising approach is the 
use of formal verification to prove mathematically that software is correct. This 
paper demonstrates that the formal approach is practical for the evaluation of 
existing software. 

1.1 The Challenge: Ultra- Reliability 

Nowhere are computerized life-critical systems more pervasive than in aerospace. 
Today, there are aircraft that cannot be controlled without computer assistance. 
In the future, there will be vehicles flown completely by computer. It is imper- 
ative that their software be correct. 

The Federal Aviation Authority [4] has proposed a very ambitious standard 
for flight safety: a probability of 10 -9 of catastrophic failure during a one-hour 
flight. Meeting this standard would effectively eliminate risk from flight. The 
probability of a fatal failure during 1000 years’ worth of consecutive independent 
one-hour missions would be less than one percent. 

Can the FAA’s goal be achieved? The proposed ultra-reliability is several 
orders of magnitude from what has ever been attained for aircraft with purely 
human control. Computerized assistance, at the least, will be required if the 
FAA’s goal is to be met. Ultra-reliable software will be needed for life-critical 
applications, but it is not at all clear that conventional software development 
methods alone are capable of its production. 

1.2 The Conventional Approach 

For a system to behave reliably, its developers must know what constitutes 
correct behavior: a specification 1 is necessary. Traditional English-language 
specifications of the intended behavior of the software suffer from the imprecision 
and ambiguity inherent in natural language. Consequently, misunderstandings 
and resultant errors are common. Ultra-reliability has never been attained for 
software specified by traditional means. 

But suppose that developers could attain ultra-reliability by some modifica- 
tion of traditional methods. How would they convince an impartial skeptic that 
they had done so? The faith of the developers in their product is not sufficient. 
Certification is not a matter of faith, but of demonstration. 


J By specification in this report, we mean a description of what the software does. If we 
intend the Ada Reference Manual's sense of specification, we use the phrase Ada specification. 
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1 INTRODUCTION 


Conventional demonstrations of reliability depend heavily on empirical test- 
ing, a costly and time-consuming process that is never fully completed. Testing 
can conclusively demonstrate the existence of a particular error, but cannot 
demonstrate the general absence of all errors. Prolonged testing of software of 
any real complexity will continually reveal flaws for as long as tests are carried 
out. Error- free software is approached, at best, only asymptotically by testing. 2 

The conclusions from testing about reliability are therefore drawn in terms of 
probability. Techniques are available that enable extrapolation from relatively 
short tests to probabilistic predictions of relatively long intervals of failure-free 
operation; however, these techniques do not scale up gracefully to encompass 
intervals of thousands of years. An alternative to empirical testing is the formal 
approach. 


1.3 The Formal Approach 

By applying mathematics to the specification and demonstration of correctness 
of software, great advances in reliability are possible. The use of a formal spec- 
ification language brings the clarity and precision of mathematical logic to the 
description of the software’s intended behavior. Formal specifications provide 
the user and the implementer with an unambiguous means of communication. 

Formal verification is a mathematical counterpart to empirical testing. The 
verifier proves mathematically that software meets its specifications in all cases, 
rather than testing particular cases. Where testing is specific, verification is gen- 
eral. The tester removes flaws from software one by one. The verifier develops 
software free from flaws. 

A leader in formal methods, the ORA Corporation has developed the Pene- 
lope [8, 14, 16] verification system for specifying and verifying Ada software. 
Using Penelope, computer science professionals can ensure that software is of 
the highest reliability. This paper demonstrates how. 


1.4 Demonstrating the Formal Approach with Penelope 

NASA Goddard Space Flight Center and NASA Lewis Research Center fur- 
nished ORA with samples of Ada software. From these samples, we chose 
a demonstration case: Grady Booch’s Calendar-Utilities, 3 a commercially 
available software package. We formally specified the subprograms of the pack- 
age in the Larch/ Ada language, then formally evaluated the correctness of the 
software using the Penelope editor. We verified that many of the subprograms 
are correct, but also uncovered errors in the software during both the specifica- 
tion and verification efforts. 


2 In practice, in correcting one error, the developer risks introducing others. 

3 Copyright Grady Booch, part of the Ada Booch components 1984-1992. 
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1.4.1 The Evaluated Software 

Calendar .Utilities is an extension of the basic Calendar package built into 
Ada, and employs Calendar, along with several other packages, by means of 
with clauses. The data types of Calendar-Utilities provide several natural 
representations for time and date, including string representations. The sub- 
programs of the package convert from one representation of time to another, 
extract specific information (such as day of the week) from a time value, and 
perform arithmetic on time values. Calendar-Utilities encapsulates a rich 
set of manipulations of dates between 1901 and 2099. 

1.4.2 The Specification 

We used the Larch/ Ada specification language to state fully and precisely the 
intended behavior of each of the subprograms in the package. On the basis 
of the specifications, we informally examined and evaluated the software. We 
detected outright errors, dubious features, and hidden assumptions. 

1.4.3 The Verification 

In the second phase, we selected subprograms from the package to evaluate 
within the Penelope Ada verification environment. We proved several subpro- 
grams to be correct; we showed others to be incorrect. We confirmed some 
errors we had detected earlier, during the specification phase, and detected 
other errors. The nature of the newly found errors was telling: they had evaded 
earlier detection. Penelope uncovered these errors because the formal approach 
is rigorous and mathematical. 

1.5 Structure of the Document 

Section 2 is a self-contained overview of program verification in the Penelope 
system; the overview is provided for readers with no prior exposure to formal 
methods. Before discussing the demonstration of Penelope in detail, we de- 
scribe the subject of the demonstration. Section 3 explains the software that 
was evaluated, the package Calendar -Utilities. In Section 4 we demonstrate 
formal specification and verification in Penelope. We draw our conclusions in 
Section 5. 

Appendix A describes related work. Appendix B is the glossary for this pa- 
per. Appendix C contains the original text of the package Calendar-Utilities. 
For convenient reference, Appendix D contains the text of the built-in Ada lan- 
guage Calendar package as it appears in the Ada Reference Manual. Finally, 
Appendix E contains the full Ada and Larch/Ada text of the software, specifi- 
cation, and verification performed with Penelope. 
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2 Overview of the Penelope System 

2.1 Basics of Formal Specification and Verification 

Every software developer reasons about program semantics. When writing soft- 
ware, the developer considers, usually on a very informal level, what consti- 
tutes correct behavior and how to make the software behave correctly. Some- 
times, however, developers reason semi-formally about the behavior of software 
through thought experiments in which programs are “executed” with paper and 
pencil. 

Consider the familiar three-step swap of x and y: 


t := x; 
x := y; 
y := t; 

The following symbolic execution shows that the software does indeed inter- 
change the values of the variables x and y. The intermediate values between 
execution steps reveal the action of the software. 




X — Xintt 

y = yinit 


t 

:= x; 






X “ %init 

y = yinit 


X 

• = y; 






X = yinit 

y — 

t — x init 

y 

• = t i 






X = yinit 

y — - &init 

t — % in it 


A formal verifier reasons much the same way, but does so at the level of 
mathematical rigor, working within a mathematical model of computation for 
the computer language. 

In the first step of formal specification and verification, the verifier uses 
the mathematical language of the model to describe the intended semantics 
of the software (what the software should do). This description is the formal 
specification. Next, the verifier analyzes the software within the model to derive 
the actual semantics (what the software actually does); this analysis is the first 
step of the formal verification. In the final step of the verification, the verifier 
uses formal mathematical proofs to show that the actual semantics are the 
intended semantics; that is, that the software does what the software developer 
intended. We elaborate on each of these steps in the following subsections. 

2.1.1 Formal Specification 

Formal specifications of software are written in a formal language having a 
precisely defined syntax and semantics. The principal benefits of formal sped- 
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fication are the following: 

• Formal specifications explicitly state all underlying assumptions. 

• Formal specifications can be stated at a high level of abstraction. 

• Formal specifications provide unambiguous descriptions. 

• Formal proofs of correctness are possible. 

• Formal specification and the subsequent formal verification allow enhanced 
confidence for critical systems. 

The fundamental notion of program semantics is that of change of state; 
that is, the alteration of data. To specify a program formally is to describe 
mathematically how it transforms one state into another. We describe the 
states of a transformation by means of assertions , mathematical statements 
about those states. 

We assume that a program is called in an initial state, performs a set of 
instructions, and terminates. 4 Executing the program transforms an initial sys- 
tem state into a final state: program variables that hold certain values in the 
initial state may acquire new values in the final state, information in external 
storage is changed through I/O, and so on. We could completely describe the se- 
mantics of terminating programs by giving an exhaustive list of all possible pairs 
of initial system states and the final states into which the software transforms 
them. 

An exhaustive description of program semantics would be similar to the 
complete description of a mathematical function by the list of all ordered pairs 
(x,/(x)) of its arguments and values. The complete listing is fully adequate, 
but a formula for f(x) is vastly preferable. For most purposes, the advantages 
of the formula f(x) = x 2 over the list (1, 1), (2, 4), (3, 9), (4, 16), (5, 25), . .. 
are obvious. 

Likewise, a symbolic way to relate possible initial states to possible final 
states is vastly preferable to a mere listing of pairs of states. The symbolism most 
often used in the theory of formal verification to relate initial states, software, 
and final states is the Floyd-Hoare triple [12], a kind of assertion. The triple 

{precondition} S { postcondition } 

symbolically states that the software S transforms the system from an initial 
state in which the assertion precondition holds to one in which the assertion 
postcondition holds. 

In this notation, the swap example above is described by: 

{* = £$ntt AND y — 2/init} S = Vinit AND y — £|‘ntt} 

4 We are specifically excluding programs that are intended to run indefinitely, such as 
operating systems, I/O repeaters, and so on. 
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The triple asserts that 5, the software that performs the swap, transforms 
any given initial state in which i — x tntt and y = j fait into a final state in which 
1 — yinit a.nd y = The triple above is a specification for the swap S. 

Floyd- Hoare triples have the same advantages for specifying program se- 
mantics that formulas have for defining functions. Instead of listing all possible 
behaviors separately, we can describe the entire collection of permissible behav- 
iors symbolically. 

2.1.2 Formal Verification 

Having made a specification of the intended semantics in terms of pre- and 
postconditions, 

{ precondition } S { postcondition } 

the verifier mathematically analyzes the software for correctness. Analyzing for 
correctness is the process of formally determining whether S is, in fact, a state 
changer that brings about postcondition whenever precondition is initially true. 
The two parts to this process are predicate transformation and proofs. 

Predicate Transformation The first part of formal verification is a kind of 
symbolic execution known as predicate transformation , 5 Similar to paper-and- 
pencil execution in reverse, predicate transformation works from post condition, 
the stated goal of the software, back to the essence of what must be true before 
5 is executed. Predicate transformation calculates the weakest precondition^ 
i.e., the most general (hence, weakest in the logical sense) precondition that 
is certain to be transformed by S into postcondition. 6 The notation for the 
weakest precondition is 

wp(S } postcondition) 

The weakest precondition is the precondition in the Floyd- Hoare triple that 
describes the actual semantics of 5: 

{ wp(S , postcondition)} S {postcondition} 

Any state satisfying wp(S 1 postcondition) will be transformed by the action of S 
into a state satisfying postcondition. By calculating the weakest precondition, 
the verifier derives the actual semantics of the software within the mathematical 
model. 

Let us return to the example of the three-step swap 5 as specified above. 
Reading from the bottom up, here are the intermediate and ultimate results 
of predicate transformation of postcondition through S. As a careful reading 

5 In mathematical parlance, the precondition and postcondition are predicates on the states. 

6 The expert in formal methods will note that, as Larch/ Ada specifications are partial 
correctness specifications, we are actually interested in the “weakest liberal precondition”; 
and, in addition, our predicate transformers compute an approximation to the weakest liberal 
precondition. For the purposes of this discussion, these distinctions can be ignored. 
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shows, at each intermediate step, predicate transformation has calculated what 
must be true if the remaining code is to establish postcondition . 


{y = Uinit AND X = Zintf) 

wp(S , postcondition) 

t := x; 

{y = Uinit and t = z<„i,} 

(2) 

X := y; 

{x = Uinit AND t = Xinit } 

(1) 

y := t; 

{X = Uinit AND y = Xinit } 

postcondition 


Formal Proof The second part of formal verification is the demonstration 
that the calculated actual semantics agree with the specified intended semantics. 

When the specified precondition logically implies the calculated weakest pre- 
condition, the semantics do agree. The specified precondition will be true in 
every initial state allowed by the specification. From the logical implication, it 
follows that the weakest precondition will also hold in every initial state allowed 
by the specification. From the definition of weakest precondition, it follows that 
5 brings about the postcondition in the final state, as desired. Thus the actual 
behavior is the intended behavior. 

The formula relating the specified and weakest preconditions is the verifica- 
tion condition or VC: 

precondition — + wp(S i postcondition) 

Proving the verification condition verifies the software. 

To illustrate, we show the VC of the three-step swap above: 

(x = x init AND y = Uinit) -» (y = Uinit AND x = x init ) 

Since the conclusion of the VC differs from the hypothesis only by rearrange- 
ment, the VC is easy to prove. The software is formally verifiable. 

2.1.3 Summary 

• The specified precondition and postcondition describe the intended be- 
havior of the software. 

• Predicate transformation is symbolic execution for the purpose of deter- 
mining the actual semantics of the software. 

• The logical formula connecting the actual semantics and the intended 
semantics is the verification condition (VC). 

• Proving the VC shows that the software’s actual semantics are the in- 
tended semantics. 
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2.2 Formal Specification in Larch/ Ada 

We have described, in general, formal specification using Floyd-Hoare triples. 
This section outlines formal specification using the Larch/Ada language. Larch/ 
Ada consists partly of an adaptation of the Floyd-Hoare notation, and partly of 
a means for defining mathematical vocabulary. Its written form is designed to 
be readable by the Penelope verification environment. In this section, we show 
a Larch/Ada specification as it looks in Penelope. 

2.2.1 Mathematics and Programming 

There are both mathematical and programming expressions in a Floyd-Hoare 
triple. In a triple 

{. precondition } 5 {postcondition} 

the statement S is written in a programming language (in this case Ada), while 
the precondition and postcondition are written in the specification language (in 
this case Larch/Ada). 

Although some programming languages are mathematically oriented, they 
are not purely mathematical. The essential difference is that programming 
languages are executable while mathematical language is descriptive. 

Consider for example the Ada operation + and the mathematical operation 
+. The ada expression x + y invokes a computation that may return a value, 
but may also raise a numeric exception if the arguments are too large. The 
mathematical expression x -f- y, on the other hand, is completely descriptive: it 
simply denotes the sum of the values of the variables. The Ada expression is an 
instruction; the mathematical expression is a description. 

In Larch/Ada, as in all specification languages in the Larch [10] family, 
the distinction between the two languages is carefully maintained. Larch/Ada 
cleanly separates mathematical and programming concerns. Mathematics is 
done in a language in which terms have their ordinary mathematical meanings. 
Programming is done in Ada, where expressions have their ordinary computa- 
tional effects. 

2.2.2 The Two-Tiered Approach 

Larch/Ada, following the the Larch paradigm, has two major divisions or tiers: 
one for pure mathematics, one for an interface between mathematics and pro- 
gramming. The mathematical tier defines the mathematical vocabulary used in 
the specification. The interface tier specifies the behavior of programs. 

The Mathematical Tier In the mathematical tier we employ the Larch 
Shared Language , common to the entire Larch family, to group together decla- 
rations of kinds of mathematical objects, declarations of functions, and defini- 
tions of objects and functions into collections called traits. In a trait, we first 
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declare sorts — collections of abstract mathematical objects. There are sorts 
of integers, of lists, of stacks, of queues, of trees, and so on. We next de- 
clare the functions that operate on the sorts. Examples of functions from the 
sort of stacks are push , pop , top, and so on. We then define the functions 
mathematically with axioms and lemmas. An example is the axiom on stacks, 
pop(push(element } St)) — element . 


The Interface Tier In the interface tier, we use the Larch/Ada interface 
language to describe the correspondence between the mathematical and pro- 
gramming realms. Part of the correspondence is built into Larch/Ada. Ada 
types are based on the Larch sorts modeling them. That is, Ada objects of a 
given type take their values in the corresponding Larch sort. For instance, Ada 
type integer is based on the mathematical integers of Larch sort Int. The set 
of all possible values of the type form a subset of the sort. The possible values 
of Ada type integer range from minint to max int within sort Int, which is 
infinite. 


Two-Tiered Specification Building on this foundation, we specify the soft- 
ware. There are special idioms for specifying the values of objects, for specifying 
the conditions that must hold when a program is called, for specifying what will 
be true upon normal exit, and for specifying the circumstances under which 
exceptions will be propagated and the consequences of doing so. 

An example of the interplay of the two tiers is shown below in the Larch/ 
Ada specification of fact, an Ada function to compute factorials. In Penelope, 
Larch/Ada appears as Ada commentary, set off with “ — I”. The specification 
below shows a Larch trait, the Ada function, and the pre- and postconditions 
of the triple after the function. 


— I TRAIT T IS 

— I INTRODUCES 


— I factorial: Int-> Int; 

— -I AXIOMS: FORALL [m:Int] 


— 1 fO: factorial(O) = 1; 

— I f plus : (m > 0) -> (factorial(m) 


— I END AXIOMS; 

— I LEMMAS: 

--I END LEMMAS; 


m*factorial(m-l)) ; 


FUNCTION fact(n : IN integer) RETURN integer; 

— I WHERE 

— | IN (n>=0) ; 

— 1 RETURN f actorial(n) ; 
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— I EID WHERE; 

TYait T, appearing before the Ada function, introduces the mathematical 
factorial function, then defines it through axioms fO and fplus. 

Note that because we use the ASCII character set for machine-readable 
Larch/Ada, our mathematical language looks somewhat like a programming 
language. There is no possibility for confusion, however, if the reader bears in 
mind that the “ — I” marker precedes mathematical notation. 

The vocabulary newly defined in trait T is used in the Larch/Ada interface, 
between “WHERE” and “EID WHERE”. 

The II annotation gives the precondition of fact: the value of the argument 
n must be non-negative. 

The RETURI annotation gives the postcondition: the value returned by the 
function must be factorial (n) . 

Note: While Larch/Ada has idioms for side-effects on globals, and for ter- 
mination by propagating exceptions, those idioms do not appear here. Their 
absence means that fact must have no side effects and must not terminate 
exceptionally. 7 

2.2.3 Summary 

• Larch/Ada cleanly separates mathematical and programming concerns. 

• The Larch/Ada mathematical tier provides the mathematical vocabulary 
for the interface tier. 

• The Larch/Ada interface tier makes explicit connections between math- 
ematics and programming, specifying program behavior in mathematical 
terms. 


7 This statement is almost correct as it stands. Please see the discussion of correctness in 
Section 4.4.1. 
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2.3 Formal Verification in Penelope 

We have described, in general, formal verification using predicate transformation 
and proofs of VCs. This section outlines formal verification using the Penelope 
system. In this section, we show how we use Penelope to evaluate a piece of 
software. 

2.3.1 Computer-Assisted Verification 

Penelope is an environment for verifying Ada programs. From Ada input and 
Larch/ Ada specifications, Penelope automatically performs the predicate trans- 
formations, calculating the pre- and postconditions and producing verification 
conditions. The verifier then uses Penelope’s built-in proof editor to prove the 
VCs. 

The entire process is interactive and incremental. Any user of a spread- 
sheet will find Penelope’s approach familiar. The verifier edits the software, the 
specifications, or the proofs. Each change is propagated throughout the file by 
predicate transformation. Viewing the recalculated results, the verifier makes 
another change. The process continues until the verifier has proved all the VCs. 
The final product is verified, legal Ada code. 

2.3.2 Larch/Ada in Penelope 

As we mentioned in the last section, Larch/Ada appears in a Penelope file as 
Ada commentary, set off by the special mark “—I”. Likewise, displayed pre- 
conditions, VCs, and proofs are Ada commentary. Thus the output of Penelope 
will always be a legal Ada program and verified output will be a correct Ada 
program. 

2.3.3 Evaluating Existing Software 

Proving Correctness When we use Penelope to verify an existing Ada pro- 
gram, we must add our Larch/Ada specifications to the Ada program. As we do 
so, Penelope interactively computes and displays the VCs that we must prove. 
When we have proved them, we have formally proved that the software meets 
its specification. 

Detecting Errors When we cannot prove program VCs, it may be because 
the software does not meet its specification or because we simply have not 
thought of the correct approach to the proof. 

However, when the software is incorrect, we can usually find out by exam- 
ining the proofs. Having located an error this way, we may confirm it with 
a special-purpose test run of the software. Penelope augments testing, rather 
than replacing it. Formal verification can demonstrate correctness; testing can 
demonstrate incorrectness. 


12 


2 OVERVIEW OF THE PENELOPE SYSTEM 


Below, we show how we used Penelope to evaluate two versions of the Ada 
procedure swap: one correct, one incorrect. Both versions have the same speci- . 
fication: 

PROCEDURE swap(x, y : IF OUT integer) 

— | WHERE 

— I OUT ( (x=IF y) AID (y=II x)); 

— I EFD WHERE; 

If we had wanted to restrict the initial state, we would have explicitly speci- 
fied the precondition with an II annotation. Not giving one implicitly specifies 
a precondition of TRUE. Since TRUE holds in any state, we are allowing any initial 
state for swap. 

With the Larch/Ada OUT annotation, we are specifying that the final value 
of x is the initial value of y, and vice versa. 

It is trivial to verify the correct version. The completed proof of the VC fol- 
lows the specification, set off by the marker “ — The computed precondition 
of the procedure body is also set off this way. 

— I Verification status: Verified 
PROCEDURE good_swap(x, y : II OUT integer) 

— I WHERE 

— I OUT ((x=IN y) AID (y=II x)); 

— I EID WHERE; 

— ! VC Status: proved 
— ! BY synthesis of TRUE 

— i n 

IS 

t : integer; 

BEGIN 

~ ! PRECONDITION = ((y=IN y) AID (x=II x)); 

t:-x; 

x:=y; 

y:=t; 

END swap; 

After we entered our specification, Penelope calculated the precondition of 
the procedure body, and from the precondition, Penelope calculated the VC. 
Since x = IN x in the initial state (and likewise for y) Penelope was able to 
simplify the VC to TRUE before displaying it for proof. We proved the trivial 
VC immediately. Since the proof is completed, Penelope does not display the 
VC, 

We may locate the error in the incorrect version by inspecting the VC: 
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— ! Verification status: lot verified 
PROCEDURE bad_swap(x, y : II OUT integer) 

— I WHERE 

— I OUT ((x=II y) AID (y=II x)); 

— I EID WHERE; 

— ! VC Status: +* not proved ** 

— ! » (x=y) 

— ! <proo*> 

— ! □ 

IS 

t : integer; 

BEGIN 

— ! PRECOIDITIOI = ((x=II y) AID (x=II x)); 

t :=x; 

y:=t; 

x:=y; 

END swap; 

Having no assumptions about x and y in general, we could not prove the VC. 
Looking at the code, we saw that the equation x = y arises from the incorrect 
order of the assignments. The program will always set x and y to the same 
value: namely, IN x. 

2.3.4 Summary 

• The user of Penelope enters Ada software and Larch/Ada specifications. 

• Penelope computes preconditions and VCs. 

• The user edits proofs of the VCs. Penelope checks the proofs for correct- 
ness. 

• When all VCs are proved, the Ada software is verified. 

• Unprovable VCs are evidence of errors. 
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3 Test- Case Software 

So that we could demonstrate formal specification and verification in Penelope 
on actual software, rather than artificial examples, NASA furnished ORA with 
a commercially obtained copy of Grady Booch’s Calendar-Utilities pack- 
age. This package provides several convenient ways to represent and manip- 
ulate times and dates between the years 1901 and 2099 A.D., going consid- 
erably beyond what is built into the Ada language. The full Ada text of 
Calendar-Utilities appears in Appendix C. Here, we describe the package 
conceptually. 

3.1 Data Types 

Dates and times are expressed in units of years, months, days, hours, minutes, 
seconds and milliseconds. 

A date can be expressed two ways. The first is by giving the year, the month, 
and the day of the month. The second is by giving the year and the day within 
the year. Both (1991, February, 2) and (1991, 33) express the same date. 

The expressions of date and time are represented by three kinds of data type: 
numeric, enumerated, and string. 

3.1.1 Numeric Representations 

There are two explicit numeric representations of date and time, and one implicit 
representation of date. 

• Type Time 

This record type represents a date and time by year, month, day, hour, 
minute, second, and millisecond. 

• Type Interval 

This record type represents passage of time in units of days, hours, min- 
utes, seconds, and milliseconds. 

• Year and Day (Implicit) 

Several functions of the package have the-year and the_year_day in their 
argument lists to represent the date. 

3.1.2 Enumerated Representations 

Names of the months and days of the week are represented by enumeration 
types. 


3.2 Operations 


15 


• Type MonthJTame 

(January, February, March, April, May, June, July, August, September, 
October, November, December) 

• Type Day Jlame 

(Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday) 

Note that the week is unconventionally listed from Monday instead of its 
first day, Sunday. This unconventionality can lead to confusion in reading the 
code of the package unless it is kept in mind. 

3.1,3 String Representations 

Dates and times represented by strings can each have two formats. 

• Date 

— Full (US standard) 

Example: "March 2, 1991" 

— Month-Day- Year 
Example: "03/02/91" 

• Time 


— Full (hours, minutes, seconds, milliseconds, am/pm) 

Example: "01:23:45:67 pm" 

— Military (24 hour clock) 

Example: "13:23:45:67" 

3.2 Operations 

There are two categories of operations on data types: extractors of information 
and converters between representations. We give informal, English descriptions 
of the operations here. We formally specify them in Section 4.2.2. 

When two or more functions share a name, we briefly indicate in a paren- 
thetical comment what kind of argument each function takes. 

3.2.1 Extracting Information 

• IsXeap.Year 

This Boolean function tells whether a given year is a leap year. 

• DaysXn (Year) 

This function calculates the number of days in a given year. 
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• Days_In (Month) 

This function calculates the number of days in a given month. 

• DayJDf (Year, Day) 

This function calculates the day of the week of a given year-day pair, 

• DayJJi (Time) 

This function calculates the day of the week of a date and time given in 
the representation of type Time. 

• PeriodJDf 

This function tells whether a given date/time is a.m. or p.m. 

3.2.2 Converting Between Representations 

• MonthJ3f (Month Number) 

This function converts the representation of months from numeric to enu- 
merated. 

• MonthJDl (Month Name) 

This function converts the representation of months from enumerated to 
numerical. 

• Time_Oi (Year, Day) 

This function converts dates from the year-day representation to the Tine 
representation. 

• TimeJDf (Time) 

This function converts time from the Calendar-Utilities Time represen- 
tation to the built-in Ada C al end ar. Time representation. 

• Time_0f (Calendar. Time) 

This function converts time from the built-in Ada Calendar . Time repre- 
sentation to the Time representation. 

• Date_Image_Of 

This function converts dates from the Time representation to a string 
representation. 

• Value_0f (Date/Time Strings) 

This function converts date and time from a string representation to the 
Time representation. 


Operations 
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DurationjDf 

This function converts time from the Interval representation to the built- 
in Ada Duration representation. 

Interval J}f 

This function converts time from the built-in Duration representation to 
the Interval representation. 

ImageJDf 

This function converts time from the Interval representation to a string 
representation. 

Value _0f (Interval String) 

This function converts time from a string representation to an Interval 
representation. 
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4 A Demonstration of the Penelope System 

This section describes our formal verification of the Calendar-Utilities pack- 
age using Penelope. First, we present an overview of the demonstration. Next, 
we describe the specifics of the formal specification. Last, we give a complete 
account of the formal verification. 

4.1 Overview of the Demonstration 

During the first phase of this project, we developed Larch/Ada specifications for 
every subprogram in the Calendar_Util.it ies package . 8 These specifications 
provided the context for informal mathematical discussion of the correctness of 
the subprograms. We noted in the interim report that most of the subprograms 
appeared to be correct, but that three subprograms were suspect. 

In the second phase of this project, we used the Penelope Ada verification 
environment to investigate correctness formally. Our intention was to give a 
full, mathematically sound treatment of as much of the Ada code as was feasible 
with the resources available. We largely accomplished our intentions, but we 
must state some reservations. We found that, even on a Sun SPARCstation 9 , a 
verification of the entire package at one time was beyond the current capabilities 
of Penelope. 

The bookkeeping information for each individual verification was kept in 
the buffer at at all times, seriously slowing the editor. The upcoming version of 
Penelope solves this problem, supporting libraries of verified components. After 
we verify a function, we will be able to store its verified text in a library and 
eliminate the bulk of its text from the buffer. Any time we need information 
about the function, we will retrieve it from the library. 

We were also hampered by Penelope’s incomplete support for strings. Pene- 
lope supports only unconstrained arrays and does yet not have string literals. 
We acknowledged both limitations and narrowed our scope to those subpro- 
grams in the package that do not involve strings. Six subprograms of twenty 
involve strings; of the remaining fourteen, we treated eleven in complete detail. 

To perform the verification, we needed to expand both the Ada and the 
Larch/Ada text beyond what we presented in the interim report. These ex- 
pansions were in three categories: additional specified Ada code required for a 
complete verification; additional theoretical facts; and additions and modifica- 
tions to the Ada code necessary to circumvent limitations of Penelope. 

The specification required enlargement. There are several dependencies in 
Calendar-Util it ies involving many calls to subprograms in other packages. To 
represent formally the effect of these calls within Penelope, we needed to specify 
the called subprograms. For each package upon which Calendar-Utilities 

8 Copyright Grady Booch, part of the Ada Booch components 1984-1992. 

9 Sun is a trademark of Sun Microsystems, Inc. SPARCstation is a trademark of SPARC 
International, Inc. 
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depends, we needed an (Ada) package specification, fully specified in Larch/ 
Ada. 

We also had to enlarge the mathematical theory under which we verified 
Calendar-Utilities. Our specification included several facts of arithmetic that 
are not built into Penelope and had to be explicitly stated in the traits. Among 
these traits are certain facts about modular arithmetic, rational numbers, etc. 

The last expansion included additions and modifications to the Ada code. 
Most of the modifications to the verified Ada code were slight. One example 
is the translation of FOR loops into WHILE loops. Penelope will support FOR 
loops in the next release. Another example involves type conversion. Because 
Penelope does not currently support type conversion, we wrote special-purpose 
Ada functions whose annotated effect is to convert objects of one type into 
objects of another. The major modification was our treatment of the fixed- 
point type duration as a rational number type, constructed as a record. The 
reasons for this modification are described below in Section 4.4.1. 

The formal treatment of Calendar-Utilities was the largest undertaking 
yet for Penelope: 2938 lines 10 of code, annotation, and verification, of which 441 
lines were Ada code. Both the specification and verification phases of the project 
have demonstrated their value in assuring correctness and detecting errors in 
actual Ada programs. 


I0 before reformatting for this report 
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4.2 Specification 

In Section 2, we described the general aspects of formal specification and the 
Larch/Ada language. In this section, we discuss Larch/Ada traits further, and 
we present detailed specifications of the CalendarJJtilities subprograms. 

4.2.1 Mathematical Preliminaries 

The specification of a program is written in the context of a logical theory 
defined by a single main trait, in which all of the mathematical vocabulary is 
introduced and defined. In a modular fashion, the main trait is built up from 
smaller component traits. Any trait may include another trait as a component, 
using a facility much like the Ada with facility for library unit dependencies. In 
this section, we describe the various component traits used for the specification. 

Component traits comprise two classes: a class of traits that the system 
implicitly generates in response to the Ada text, and a class of traits that the 
user explicitly constructs. 

System-Generated Traits Just as an Ada program runs within the envi- 
ronment of the package standard, the main larcli trait implicitly includes (as 
though with an include statement) a standard trait that defines Ada’s built-in 
data types. The standard trait defines the following: the integer sort Int and 
its associated operations (+, *, etc.); the enumeration sort AdaBool with its 
literals (TRUE, FALSE) and its operations (AID, OR, I0T, etc.); and other basic 
sorts, objects, and operations. Ada type integer is based on Larch sort Int, 
boolean is based on AdaBool, and so on. This standard trait essentially gives 
the theory governing Ada package standard. 

In addition to the standard trait, the system implicitly generates other traits 
to provide the abstract data sorts on which Ada’s constructed types are based, 
together with the theory of those sorts. For example, if a user declares the Ada 
type 

TYPE color IS (red, amber, green); 

the system implicitly generates a Larch/Ada trait and implicitly includes the 
trait in the main trait for the Ada program. This trait makes available a new 
enumerated sort on which to base color, together with the theory that makes 
it the proper enumerated sort. 

In general, when a type T occurs in a program, Penelope creates the sort on 
which T is based. The mathematical operations on the sort use similar syntax 
to Ada operations on T, and so can be understood with little difficulty. 

The Penelope system generates an internal name for each sort it creates. For 
example, the internal name for the sort on which the enumeration type color 
is based, is essentially a listing of all its enumeration literals 

(red, amber, green) 
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Since such internal names can become unwieldy, we have added notational ex- 
tensions to Larch by which the user may introduce more convenient names for 
these sorts. A full description of implicitly generated traits and our notational 
extensions to Larch is given in ORA Technical Report TR 89-34 [7], 

User- Constructed Ttaits The user can construct traits to gain additional 
expressiveness or convenience. For example, in specifying Calendar-Utilities, 
we constructed traits to introduce new sorts, to give convenient names to exist- 
ing sorts, to define conversion factors between time units, and to define various 
auxiliary functions from one time representation to another. 

Traits contain both axioms and lemmas. The axioms express the theory 
in the form best suited to mathematical exposition. The lemmas encapsulate 
essential facts of the theory in a form best suited to proving VCs. In construct- 
ing our traits, we tried to write the axioms and lemmas in a style that appeals 
directly to people’s usual understanding of the calendar. For example, when 
specifying the predicate is _leap_year, our aim was to provide a more straight- 
forward notion of a leap year than the code for that function can provide and a 
more clearly stated specification than dense mathematics would provide. 


Current Limitations of Traits in Penelope While the mathematical the- 
ory underlying Penelope is mature and adequate for formal verification, Pene- 
lope itself is still being developed. Consequently, we had two limitations on 
traits as input. 

The first limitation is Penelope’s syntax for traits. The Penelope syntax 
for traits is an extract of and somewhat different from the syntax in the Larch 
manual, although most of the differences are minor, reflecting the embedding of 
traits as commentary in Ada code. 

The other limitation involves sortchecking of the logical language. Penelope’s 
sortchecking is still being developed. The present sortchecking is too lenient, 
which means that the user must perform some of the sortchecking manually, 
exercising care not to present certain kinds of ill-sorted terms to Penelope. Only 
record terms concerned us directly in verifying Calendar-Utilities. 

Currently, Penelope has only one record sort, AnyRecordSort, and treats 
all record fields as naming components of this most general record sort. Since 
Ada record types are based on Larch/ Ada record sorts, the user must never 
employ the same field name in two distinct record types, for otherwise, there 
would be an invalid overloading of the corresponding Larch record field name. 
We respected this limitation in defining record types. 

Penelope effectively turns off sortchecking when treating record components, 
assigning them the most general sort AnySort, thus discarding information 
about their actual sorts. Consequently, sortchecking finds apparent ambigui- 
ties in perfectly unambiguous record terms. If a function g is overloaded, there 
may be no way for Penelope to determine the proper sort of g(R.f) 
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For instance, in Calendar-Utilities, we have the sort f ixnum representing 
rational numbers. We overload multiplication, so that Penelope has both these 
signatures in its symbol table: 

: Int, Int -> Int 
"* M : Int, tium m -> f ixnum 

As a result, Penelope treats the following equation as ambiguous: 

(i*m).numer = i*(m.numer) 

The term on the left of the equation may have any sort, so the target sort of 
the second * might be either Int or f ixnum. The sort of m.numer can be either 
Int or f ixnum. Thus, Penelope cannot determine which signature to use. 

To direct the sortchecker in these cases, we remove the apparent ambigu- 
ity, employing identity functions from given sorts to themselves. Applying an 
identity function informs the sortchecker of the sort of the argument term while 
preserving the term’s mathematical value. We can unambiguously write the 
formula as follows: 

(i*m).numer = Int_identity(i*(m,numer)) 

Now, ihe only choice of signature for + is the first signature 
"* M : Int, Int -> Int 

Summary of the Traits The full text of the Penelope verification output for 
Calendar-Utilities given in Appendix E begins with six traits that we wrote 
in order to carry out the verification. Here is a brief summary of each trait. 

• Trait Z 

Many, but not all, facts of arithmetic are built into Penelope. Trait Z 
contains additional facts about division and modular arithmetic. This 
trait also has an explicit identity function on the integers, which is useful 
for removing ambiguities during sortchecking. 

• Trait fixed-point 

The theory of fixed point numbers is not yet built into Penelope. We use 
this trait to provide needed facts. 

• Trait sort-names 

In this trait, we give all of the names of sorts that we later use to de- 
fine the vocabulary of the Larch/ Ada specification. The Ada types of 
Calendar-Utilities are based on the sorts of this trait. Some sorts have 
a M good_” predicate that asserts that a given value within the sort is a 
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legitimate representation of a date and time. The “_tic functions rep- 
resent the values of Ada attributes. The trait also defines miscellaneous 
arithmetic and sort- forcing functions. 

We introduce the enumeration sort century in order to provide the vocab- 
ulary to document that the Ada function ValueJDf provided in package 
Calendar-Utilities is correct only for argument dates in the twentieth 
century: 

SORT century IS (twentieth, twentylirst) 

Without century terms, we would be unable to express mathematically 
that “02/27/55” might refer equally well to 1955 or 2055. 

We also assign names, or aliases, to the sort Int. Penelope permits one 
or more aliases for a sort, which may be used to make the mathematics 
clearer and Penelope easier to use. Aliases are especially useful for clarity 
when several Ada types are based on the same mathematical sort. 

In the mathematical tier of this trait, we define the integers only once. All 
integer types and subtypes are based on the single infinite sort Int. Each 
type determines a subset of Int, over which its values range. 

Hence the years, months, etc., of Calendar-Utilities are all based on 
the sort Int. To declare the signatures of our mathematical functions 
clearly, it is helpful to use the following aliases: 


SORT 

years 

IS 

Int 

SORT 

months 

IS 

Int 

SORT 

month-.days 

IS 

Int 

SORT 

year_days 

IS 

Int 

SORT 

absolute^days 

IS 

Int 

SORT 

hours 

IS 

Int 

SORT 

minutes 

IS 

Int 

SORT 

seconds 

IS 

Int 

SORT 

milliseconds 

IS 

Int 


This signature declaration from trait time-representations 
day_of_year: years, months, month_days -> year_days 
shows clearly what the values in the arguments mean, whereas 
day_of_year: Int, Int, Int -> Int 
would be unenlightening. 

There are many other aliases of this clarifying nature in sort jnames. Sep- 
arate from them is the alias 
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catu ALIASES Int 

We will use this alias later when we introduce a very short, but unspecified, 
unit of time, the catu (Calendar Atomic Time Unit). Catus relate the 
abstract time values from the implementation of Calendar . time to the 
time values of Calendar-Utilities .time. 

The abstract sort Calendar. time-sort may have a smaller granularity 
than the millisecond: we do not know. By choosing to work with the small 
but unspecified catu, we do not have to know. We require of the catu 
only that it be positive and of sufficiently small granularity to represent 
faithfully times expressed in either setting. We treat it as an unspecified 
positive integer constant in the remainder of the specification. 

• Trait conversion-factors 

This trait defines the functions for converting from hours to seconds, days 
to milliseconds, etc. 

• Trait time-representations 

This trait encapsulates the theory of the individual time representations. 
We concentrate on extracting information from time values of the sort 
Time_sort on which the type Time of Calendar-Utilities is based. For 
instance, we find the number of days in a given month in a given year 
through the function days-injnonth. 

We also define predicates that indicate whether formal time values repre- 
sent possible times: good_year, good-month, good-month-day, and so on. 
We use these predicates to define the predicate good-time on an entire 
Time_sort value 

(the_year => 1990, 
the_month => 2, 
the^day => 29, 
the_hour => 12, 
the_minute => 34, 
the_second => 56, 
the_millisecond => 789) 

Since there is no February 29, 1990, this formal record value t does not 
represent an actual time. Accordingly, 

good_time(t) = false 

We can use these predicates to document that a given Ada subprogram 
will behave correctly only when its arguments represent possible dates and 
times. 
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• Trait time -representation-conversions 

This trait encapsulates the theory of converting from one time represen- 
tation to another. 

4.2.2 Detailed Specifications 

Here we present and discuss the Larch/ Ada specification of every subprogram 
in the package Calendar-Utilities obtained from NASA. The mathematics 
used in the specification is found in the traits discussed above in Section 4.2.1. 
The disambiguating comments after overloaded function names are the same as 
in Section 3. 

The style of each specification is much the same as every other. After reading 
the first few, as well as the specification of time_of (Time), the reader may wish 
to proceed to the general discussion of the specifications in Section 4,3. The 
specification of time_of (Time) deserves attention because it is the first in which 
the Ada type to Larch sort correspondence is discussed in full depth. 

Function is_leap_year 

FUNCTION is_leap_year(the_year : IN year) RETURN boolean; 

— | WHERE 

— I IN (good_year (the_year)) ; 

— | RETURN is_leap_year (the.year) ; 

— I END WHERE; 

This function calculates whether or not the given year is a leap year. The 
IN annotation uses the predicate good_year to restrict the value of the argu- 
ment the_year to the acceptable interval [1901,2099], The RETURN annotation 
specifies that the the returned boolean has value true if and only if the.year 
is a leap year, using the predicate is_leap_year to do so. 

Note from the absence of global annotations that this function must have no 
side effects. Similarly, since there are no propagation annotations, this function 
must not terminate by propagating an exception. 

Function days_in (Year) 

FUNCTION days.in (th.e_year : IN year) RETURN year_day; 

— I WHERE 

— I IN good_year(the_year) ; 

— | RETURN days_in_year(the_year) ; 

— I END WHERE; 

This function calculates the number of days in a given year. The IN anno- 
tation restricts the value of the argument the.year to the acceptable interval 
[1901, 2099]. The RETURN annotation specifies that function computes the num- 
ber of days in the year. There are to be no side effects or propagated exceptions. 
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Function days_in (Month) 

FUNCTION days_in(the_month : II month; 
the_year : II year) RETURI day; 

— [ WHERE 

“I II good_month(the_month) ; 

— I II good_year(the_year) ; 

— I RETURI days_in_month(the_month, the_year) ; 

— I EID WHERE; 

This function calculates the number of days in a given month. The year 
must also be given because of February and leap years. The first II condition 
constrains the value of thejaonth to lie in the interval [1,12]. The second 
II annotation restricts the value of the argument the_year to the acceptable 
interval [1901,2099]. The RETURI annotation specifies that the number of days 
in the month is to be computed. There are to be no side effects or propagated 
exceptions. 

Function month_of (Month Number) 

FUICTIOI month_of (the_month : II month) RETURI month.name; 

— I WHERE 

— I II good_month(the_month) ; 

— I RETURI month_name_sort_tic_val((the_month-l) ) ; 

— I EID WHERE; 

This function converts numerical months to the corresponding months within 
the enumeration type (January, February, . . . , December), The II annota- 
tion restricts the numerical month to the interval [l, 12]. The RETURN annotation 
specifies the enumeration value corresponding to the numerical month. 

The language of this specification requires some explanation. First, the 
Larch/Ada function 

month_name_sort_t ic_val 

represents the values of the Ada attribute function 

month_name 1 val 

The name of the Larch/Ada function is intended to suggest that it takes values 
in sort month_name_sort on which Ada type month-name is based. The 
is used to represent the tic (apostrophe), which is not acceptable as part of 
Larch/Ada function names. The definition ofmonth_name_Bort-tic_val is given 
in trait sort .names, found in Appendix E. 

Second, months of the calendar are numbered from 1, while Ada’s enumer- 
ation types are numbered from 0. In Ada, 'post January) has value 0, not 1. 
Subtracting 1 from The_Month is the necessary adjustment. 

There are to be no side effects or propagated exceptions. 
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Function month_of (Month Name) 

FUNCTION month_of (the_month : II month.name) RETURI month; 

— I VHERE 

— | RETURI (month_name_Bort_tic_pos(the_month)+l) ; 

— I EID WHERE; 

Months in the enumeration type (January, February, ...» December) are 
converted to the corresponding numerical months. The RETURI annotation spec- 
ifies the enumeration value corresponding to the numerical month. 

The language of this specification requires some explanation. The Larch/ 
Ada function month_name_sort_tic_pos represents the values taken by the Ada 
attribute function month-name 1 pos. Subtracting 1 from TheJConth is necessary 
to adjust from the 0-based numbering of Ada enumeration types to the ordinary 
1-based numbering of months. For more information, please read the exposition 
of the preceding Ada function. 

There are to be no side effects or propagated exceptions. 

Function day_of (Year, Day) 

FUNCTION day.of (the^year : IN year; 

the_day : IN year_day) RETURI day_name; 

— I WHERE 

— I IN goodly ear_and_day(the_y ear , the_day) ; 

— | RETURN day_name_of (the_year , the^day) ; 

— | END WHERE; 

This function calculates the day of the week for a given date. The IN an- 
notation specifies that the year and day together constitute a valid date. The 
RETURN annotation specifies that the proper day of the week is calculated. There 
are to be no side effects or propagated exceptions. 

Function day_of (Time) 

FUNCTION day_of (the_time : II time) RETURI year.day; 

— | WHERE 

— I IN good_tirae(the_time) ; 

— I RETURN day_of _year(the_time . the_year, 

the_time . the_month, the_time . the_day) ; 

— I END WHERE; 

This function differs from the previous day.ol function only in the repre- 
sentation of the given date. The IN annotation specifies that the-time is a 
good representation of a date and time. The RETURI annotation specifies that 
the proper day of the week is calculated. There are to be no side effects or 
propagated exceptions. 
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Function time_o f (Year, Day) 

FUNCTION time_of (the_year : IN year; 
the_day : IN year_day) RETURN time; 

— I WHERE 

— 1 IN good_year_and_day(the_year, the_day) ; 

— I RETURN t SUCH THAT ( 

t . the_year=the_yeax 
AND 

t . the_month=month_ol (the_year , the_day) 

AND 

t . the_day=day_of _month(the_year , the_day) 

AND 

t . the_hour=0 
AND 

t . the_minute=0 
AND 

t . the_second=0 
AND 

t - the_millisecond=0) ; 

— I END WHERE; 

This function converts the date from representation by a Year-Day pair to 
time representation. The IN annotation specifies that the Year-Day pair must 
actually represent a date. The RETURN annotation specifies that the returned 
time value will represent the same date, at the instant it begins. There are to 
be no side effects or propagated exceptions. 

Function period_of 

FUNCTION period.of (the_time : IN time) RETURN period; 

— I WHERE 

— I IN good_time(the_time) ; 

—I RETURN (IF (the_time . the_hour<12) THEN am ELSE pm); 

— I END WHERE; 

This function computes whether a given time of day is before noon or not. 
The IN annotation specifies that the_time is a good representation of a date 
and time. The RETURN annotation specifies that am is to be returned for times 
before noon, and that pm is to be returned for times from noon onward. There 
are to be no side effects or propagated exceptions. 

Function time_of (Time) 

FUNCTION time_ol (the_time : IN time) RETURN calendar. time; 
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— I WHERE 

— | IH good.timeCthe^time) ; 

— | RETURN time_to_cal_time(the_time) ; 

— I END WHERE; 

This function converts time representations to calendar .time representa- 
tions of time and date. Before we discuss its annotations, recall that the value 
of the Ada variable the-time is in Larch sort time_sort since that is the sort 
on which the Ada type time is based. 

The IN annotation specifies that the.time is a good representation of a date 
and time. The value of the_time belongs to Larch sort time -sort. Applying the 
mathematical function time_to_cal_time to this value yields the correspond- 
ing equivalent value in the sort calendar_time_sort. The RETURN annotation 
specifies that this equivalent value is the value returned by the Ada function. 

There are to be no side effects or propagated exceptions. 

Function time_of (Calendar. Time) 

FUNCTION time_of (the_time : IN calendar .time) RETURN time; 

— | WHERE 

— | RETURN cal.time.to^timeCthe^time) ; 

— I END WHERE; 

This function differs from the previous time_of function basically in that 
the representations of time are reversed: the conversion proceeds in the opposite 
direction. The IN annotation is implicitly TRUE: all calendar. time values are 
valid. The RETURN annotation specifies that value returned is the equivalent, in 
the time representation, of the original value, which is in the calendar .time 
representation. There are to be no side effects or propagated exceptions. 

Function time_image_of 

function time_image_of (the_time : in time; 

time.form : in time_f ormat ) 

return string; 

— | WHERE 

— | IN good_tirae(the_time) ; 

— | RETURN time_to_time_string(the_time, time_form); 

— | END WHERE; 

This function extracts the time of day from the given time representation 
and converts it to a string representation in the given format. The IN anno 
tation specifies that the.time is a good representation of a date and time. The 
RETURN annotation specifies that the returned string represents the input time 
in the chosen time string format. There are to be no side effects or propagated 
exceptions. 
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Function dateJ.mage_of 

function date_image_of (the.time : in time; 

date_form : in date_format) 

return string; 

— I VHERE 

— I IN good_time(the_time) ; 

— I RETURN time_to_date_string(the_time, date_f oro) ; 

— I EID WHERE; 

This function differs from the above in that it converts the extracted date, 
not time, to the chosen string representation. The II annotation specifies that 
the.time is a good representation of a date and time. The RETURI annotation 
specifies that the returned string represents the input date in the chosen date 
string format. There are to be no side effects or propagated exceptions. 

Function value.of (Date/Time Strings) 

function value_of (the_date : in string; 



the_time : in string; 
date_form : in date_format; 



time.form : in time_fonnat) 

i 

return time; 


— | 

WHERE 

[ 

— 1 

RETURI strings_to_time( the.date. 

[ 

— 1 

the_time. 

f 

— 1 

date^form, 


— 1 

time_fona, 

- 

— 1 

twentieth 

- 

— 1 

); 


— 1 

RAISE lexical.error <=> 


— 1 

(IDT well_formed_date_string(the_date, date_form)) 

1 

— 1 

OR 

i 

— I 

(HOT well.formed^time.stringfthe.time, time_form)) ; 


— 1 

END WHERE; 

" 


This function converts date and time from string representation to time 
representation. The absence of an II annotation indicates that any input is 
acceptable. The RETURI annotation specifies that the returned time value is to 
be equivalent to the representation of time and date in the given input formats. 
Notice that we have explicitly documented that the code treats every two-digit 
year as belonging to the twentieth century. The RAISE annotation specifies that 
the function will raise lexical.error if and only if the string input is invalid. 
There are to be no side effects. 
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Function duration_of 

FUNCTION duration^of (the_ interval : IF interval) 

RETURF builtin. duration; 

— | WHERE 

— | RETURF int erval_t o_durat ion ( the. int er val ) ; 

— | RETURN result SUCH THAT good.durat ion (result ) ; 

— I EFD WHERE; 

This function converts time in interval representation to time in duration 
representation. The absence of an IF annotation indicates that any input is 
acceptable. The first RETURF annotation specifies that the returned duration 
value is to be equivalent to the given interval value. The second RETURF anno- 
tation is a convenience for verification. Without it, every time that duration_of 
is invoked, the user is likely to have to prove the predicate good-duration of 
the returned value. With it, the user need only prove the predicate once, within 
the verification of durations* itself. Therever after, the predicate will auto- 
matically apply to the returned result, and need not be reproved. There are to 
be no side effects or propagated exceptions. 


Function interval_of 

FUNCTION interval.of (the_duration : IF built in. duration) RETURN 
interval; 

— I WHERE 

— | RETURN duration_to_interval(the_duration) ; 

— | END WHERE; 

This function is the inverse of the preceding function. No IF conditions need 
to be placed on the_duration, since all duration values are valid. The RETURN 
annotation specifies that the returned value is the interval equivalent of the 
input value. There are to be no side effects or propagated exceptions. 

function image.of (the_interval : in interval) return string; 

— | WHERE 

— | RETURN interval_to_string(the_interval) ; 

— | END WHERE; 

This function returns the string representation of the time in interval 
form. There is no IN annotation because all interval values are valid. The 
RETURN annotation specifies that the returned value is the string equivalent of 
the interval input. There are to be no side effects or propagated exceptions. 
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function value_of (the_interval : in string) return interval; 

— I WHERE 

— I RETURI string_to w interval(the_interval) ; 

— I RAISE lexical_error <=> 

I ROT well_formed_interval_string(the_interval) ; 

— I EID WHERE; 

This function converts time intervals in string representation to time inter- 
vals in interval representation. All inputs are acceptable: there is no explicit 
IH annotation. The RETURI annotation specifies that the returned interval 
value is to be the equivalent of the input string interval value. There are to 
be no side effects or propagated exceptions. 
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4.3 Discussion of the Specification 

In this section, we first explain our approach for formally specifying existing 
software. We then describe the problems with the Calendar-Utilities package 
that were revealed when we specified the package. 

4.3.1 Formally Specifying and Verifying Existing Software 

Ideally, we formally specify software before it is written, and write the software 
in tandem with verifying it. Formal methods are best applied to a program 
when it is under development. In practice, however, we often specify and ver- 
ify existing software, that is, software written previously, independently of us. 
Although verifying existing software applies only part of the strength of formal 
methods, we still can uncover problems with software. 

When verifying existing software without an original specification, we cannot 
absolutely know what the software was meant to do. We make assumptions in 
writing the specification and we document those assumptions. We then verify 
the software with respect to our specifications. 

In the case of the Calendar_Utilities package, we used the following ap- 
proach to specify the software. First, for reasonable inputs, we specify that the 
output be what people would expect. For example, a reasonable input for a 
date could be March 2, 1991, and people would expect a conversion of that date 
to be 03/02/91 (in terms of the string representation formats in the program). 
Second, we specified that the input must be reasonable. The functions we were 
given accept unreasonable inputs without complaint. For example, the function 

function Time_0f (The_Time : in Time) return Calendar .Time ; 

as written accepts impossible dates (e.g., March 31) and returns invalid values 
for type Calendar .Time without raising an exception. If the invalid values are 
then passed as arguments to operations of package Calendar, an exception will 
be raised. 

We used restrictive IN annotations to show that the Time_0f can be trusted 
only on certain inputs. 

We verify the software with respect to our assumptions and specifications. 
The demonstrated correctness of a program assures that the program satisfies 
our mathematical statement of its behavior; a formally based judgement of 
incorrectness assures that the program does not satisfy our description of its 
intended behavior. 

4.3.2 Discussion of the Software 

For most of the Calendar_Utilities subprograms, the Larch/Ada specifica- 
tions document the clearly intended design of the software. Informal inspection 
assured us that the design was well implemented. However, the entire pack- 
age was not problem-free. We found and documented subprograms that do not 
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guard against unsafe arguments, that is, arguments that lead to unexpected 
results. Of greater concern, we also found dubious features and outright errors 
in the software. 

Software with No Apparent Problems Functions such as Is-Leap.Year 
presented no difficulties. The II annotation is practically trivial: the year lies in 
the intended range. There are no RAISE annotations. We informally determined 
that this function will behave as intended for all permissible inputs. 

Software with Minor Problems We found that some functions, such as 
DayJDf (Time) and TimeJDf , do not guard against unsafe arguments. We there- 
fore specify, for example, that the Time value passed to DayJ3f must not rep- 
resent such impossible dates as September 31. The II annotation defines the 
acceptable input values. 

Contrast this with function ValueJDf (Date/Time Strings), which does guard 
against unsafe values by raising exceptions. We document what these unsafe 
arguments are with the RAISE annotation. The II annotation can be the trivial 
condition TRUE, because ValueJDf can be called with any input. 

Problematic Software We begin by describing some shortcomings in the 
software that we found in the process of performing the specification. Related 
to the above-mentioned numerical representations of impossible dates, there is 
unfaithful extraction of information represented in strings. 

In the function ValueJDf (Date/Time Strings), which takes a string and 
returns a Time record, the year from “02/27/55” becomes 1955. This assumption 
that all two-digit year dates represent years in the twentieth century is dubious, 
particularly for software written so near the end of the century. The software 
should have a century parameter to allow the user to select the century for the 
date. (We have such an argument in our specification function, but its role is 
purely documentary, not restrictive. The software, not merely the specification, 
needs to take centuries into account.) 

We found this dubious feature while attempting to define an inverse to the 
original mathematical record- to-string conversion: the inverse did not exist be- 
cause century information was being thrown away. We therefore defined the 
sort century to carry the necessary information. 

After completing the specification, we systematically compared the software 
with the description of what it should do, though this comparison was of course 
informal. We marked a number of problems in the software for closer examina- 
tion, the most salient three are listed below. We tested these problems before 
the verification phase and determined that two of the problems were indeed 
errors, while the third was a dubious feature of the software. 

We had one difficulty with testing that requires explanation. Of the library 
units that Calendar-Utilities depends upon, several were available to us only in 
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incomplete form and were not compilable. To run our test cases after we identi- 
fied potential errors, we removed sections of the software and wrote a handful of 
lines so that the necessary units would compile. None of our alterations affected 
the software in CalendarJJtilities undergoing formal analysis. 


First Problem In the body of CalendarJJtilities, ValueJJf (Date/Time 
Strings) contains the following lines of software (some of the initial lines are 
omitted). 


function Value.Of (The_Date 
The_Time 
Date_Form 
Time.Form 

return Time is 

Result : Time; 

Left_Index : Positive; 
Right_Index : Positive; 
begin 


in String; 
in String; 
in Date_Format 
in Tiae.Format 


Full; 

Full) 


case Time_Form is 
when Full => 

Right_Index := 

String_Utilities . Location.Of 
(The .Character => Blank, 

In_The_String => 

The_Time (Lef t.Index . . The_Time 9 Last ) 

); 

Result .The_Millisecond := 

Millisecond(Iatural_Utilities . Value_0f 
(The_Time 

— ( 1 )*** 

(Left.Index .. (Right_Index - i)))); 
Left_Index := Right_Index + 1; 
if Period* Value (The_Time 

(Left_Index .. TheJTime’Last)) = PM then 
if Result . The.Hour /= loon then 
Result .Thejiour : = 

Result .The_Hour + loon; 
end if ; 
end if ; 

when Military => 

Result .The_Millisecond := 

Millisecond(Fatural_Utilities . Value_Of 


36 


4 A DEMONSTRATION OF THE PENELOPE SYSTEM 


— ( 2 )*** 

(The_Time(Left_Index .. TheJTime'Last) ) ) ; 

end case; 
return Result; 
exception 

when Constraint_Error => 
raise Lexical.Error ; 
end Value_0f ; 

Value _0f takes two string representations of time (e.g., “FEBRUARY 27, 
1955” and “01:21:06:30 PM”) and extracts the corresponding numerical com- 
ponents to build a record representation. The assignments indicated by (i) 
and (2) in the code above take hundredths of a second (the “30” from the sec- 
ond string above) and insert the millisecond component into the record. There 
is no multiplication by 10, so the milliseconds in our example are recorded as 
30, instead of 300. Re-conversion back to a string, using the correct function 
Time_Image_Df (employing the expected division by 10) produces the different 
string “01:21:06:03 PM”. 

Second Problem In the body of package CalendarJJtiliti.es, the function 
Duration_Of (which immediately follows Value JOf) is as follows. 

function Duration_Of (The_Interval : in Interval) 

return Duration is 

begin 

return ( Duration(lnteger(The_Interval.Elapsed_Days) 

* £>econds_Per J)ay) + 

Duration(Integer(The_Interval.Elapsed_Hours) 

* Seconds_Per_Hour) + 

DurationXlnteger (The. Interval , Elapsed_Minutes) 

* Seconds_Per_Minute) + 

Duration(The_Interval . Elapsed_Seconds) + 

— ( 1 )*** 

Duration(The_Interval . Elapsed.Milliseconds / 1000)); 
end Duration.Of; 


This function takes a record representation of time and returns a numerical 
fixed-point representation. In line (1), an integral number of milliseconds is 
intended to be converted into a fractional number of seconds. Thus 276 mil- 
liseconds should convert to 0.276 seconds. The conversion to fixed-point type 
Duration occurs, however, after integer division. Millisecond values are be- 
tween 0 and 999 and hence will always produce 0 when divided by 1000. Thus, 
DurationJJf wrongly converts any Interval record into a whole number of 
seconds. 
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Third Problem Consider again the function Value _0f (Date/Time Strings). 


function Value_0f 

(The_Date : 

in 

String; 


The_Time : 

in 

String; 


Date_Form : 

in 

Date_Format := Full; 


Time_Form : 

in 

TimeJFormat : = Full) 

return Time is 




Result : 

Time; 



Left_Index : 

Positive; 



Right_Index : 

Positive; 




begin 

case Date_Form is 

when Full => 

when Honth_Day_Year => 


— ( 1 )*** 


Result .The_Day := Day(Iatural_Utilities . Value_0f 
(The_Date (Left_Index .. (Right.Index - 1)))); 


end case; 
end Value_Of; 

In line (1), which occurs in the first case statement of the software, the day 
of the month is selected from the date string. Thus if the string is “FEBRUARY 
27, 1955”, we wish to select the “27” and then convert it to the integer value of 
27. An Ada slice is taken, using 

(Left.Index .. (Right.Index - 1)) 

In our example, the Ada 'first and 'last values of the slice are 10 and 11, 
respectively. This fairly arbitrary slice is then passed to the separate pack- 
age laturalJJtilities for conversion to a numerical value. A better approach 
might be to “normalize” the slice to one whose range was 1..2, rendering the soft- 
ware robust across differing implementations of the laturalJJtilities pack- 
age. In fact, the package HaturalJJtilities that came with the software was 
written assuming that strings began at position 1, and an exception was raised 
when we ran Value_0f on this example. 
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4.4 Verification 

In Section 2.3, we described formal verification in Penelope in general terms. In 
this section, we will describe the verification of Calendar-Utilities in detail. 

First, we place qualifications on our results. Second, we comment briefly on 
the subprograms that we fully verified. Third, we discuss the errors we detected. 
Finally, we summarize the results. 

4.4.1 Qualifications of the Results 

When we state that software has been verified as correct using Penelope, we 
must consider three qualifications. First, we are working within Penelope’s 
program semantics, which do not model all the possible behaviors of an Ada 
program. An Ada program correct in the Penelope semantics may still have 
certain unacceptable behaviors. Second, correctness is verified with respect to a 
specification that may not exactly reflect the developer’s intention. Third, the 
correctness is verified for a modified version of the Calendar-Utilities code. 
Because Penelope is still being developed, we had to modify the code to be in 
the subset of Ada that Penelope currently supports. Some modifications were 
major changes to the code, and others were minor changes to accommodate the 
limitations of Penelope. 

Correctness Within Penelope’s Program Semantics Our notion of cor- 
rectness is termed partial correctness. Partial correctness means that a program 
is correct if whenever it is started in a state that satisfies all of its initial con- 
ditions and the program also halts, it halts in a state that satisfies all of its 
final conditions. The program may, however, fail to halt. A program that loops 
forever will be correct by our semantics. 

Fortunately, failure to halt is not a concern in this effort, since the only iter- 
ation constructs in the verified code are FOR loops, which have been transformed 
into equivalent WHILE loops. The upper bounds have predefined maximum val- 
ues. There are no recursively defined routines. 

Secondly, our notion of correctness excludes the possibility of numeric over- 
flow or storage error. The formal basis of Penelope deliberately omits them. 
Penelope verification is predicated upon programs not raising those exceptions. 

For a fuller description and discussion of the meaning of a complete Penelope 
verification, see Guaspari [9], 

Specifications The software is proved to meet specifications that we supplied. 
If our specifications are not the proper ones, the verification of the software is 
irrelevant. For the verification to be relevant, we must reflect the intent of the 
developer. 

We must also define the logical theory correctly. If the vocabulary from 
the theory does not have its intended meaning, or worse yet, if the theory is 
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self- contradictory, the verification is suspect. Furthermore, the asserted lemmas 
may not actually follow from the axioms. Currently, the only safeguard against 
these defects is the expertise of the verifier. Efforts are underway to provide 
automated assistance to users of Penelope in constructing theories. 

Major Changes to the Code There are four types representing time in 
package Calendar-Utilities. There is the private type Time from the package 
Standard. Calendar, the record type Time of the package Calendar-Utilities, 
the record type Interval of the package Calendar-Utilities, and the built-in 
fixed-point type Duration. The first three types presented no problems, but we 
had to make major changes to the code to treat the last type. 

The Ada Reference Manual does not specify a concrete implementation for 
the private type Time, nor does the concrete type matter so long as we are 
able to represent values of types year number, month-number, day_number and 
day-duration as objects of type time in a manner that respects the operations. 
We must be able to convert to type time, add, subtract, compare and sub- 
sequently convert back to the correct values by means of the functions in the 
package. Beyond this, the particulars of type time are irrelevant. 

We used integer as the concrete type for Time: it satisfies all the necessary 
conditions. We conceive of time as integer multiples of a fundamental unit, the 
catu (calendar atomic time unit), of which all of our other time units are integer 
multiples. The traits describe the theory for converting between all our discrete 
representations of time, all based on the catu. 

Everything would be completely straightforward if it were not for the fixed- 
point type duration. ORA has addressed the theory of real number types [11], 
and real number verification will be melded with Penelope in Penelope/ Ariel, 
schedule for release in 1992. In the meantime, we must give some treatment of 
the fixed-point type Duration. 

We changed the Ada declaration of Duration to be a record type pairing 
numerator and denominator; we based all fixed-point numbers and operations 
on the rational numbers under addition and multiplication. In doing so, we 
assumed that the error inherent in rounding, addition, assignment, and so on is 
too small to affect the basic correctness of our results. 

Because fixed point operations in Ada are not exact, while our rational 
operators are, a critic could reasonably argue that our verification should be 
performed again in Penelope/Ariel, which supports real number types. We feel, 
however, that our treatment of fixed-point types was sufficient for us to certify 
the correctness of some subprograms and to detect the incorrectness of others. 
The differences between rational and fixed-point operations should be negligible. 
We would expect no surprises under subsequent re- verification. 

Accommodating Limitations of Penelope To accommodate the limita- 
tions of our current editor, we made minor changes to the code and performed 
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some tasks manually. The changes we made to the code were innocuous. These 
changes included translating the Ada text to lower case, using the fully quali- 
fied forms of several names, converting from one type to another with function 
calls instead of with explicit type conversions, translating FOR loops to equiva- 
lent WHILE loops. In addition, we altered the form of certain procedure cadis in 
order to satisfy Penelope’s conservative restrictions against potential aliasing. 
We removed the declarations of exceptions because Penelope does not yet sup- 
port their Ada declarations; they sue, however, implicitly declared by mention 
in Larch/ Ada. Finally, we changed named parameter associations to positional 
parameter associations. None of these changes affected the Ada semantics. 

We overcame other limitations by doing manually what Penelope does not 
yet do automatically. We explicitly coded range constraint checks. We type- 
checked Ada expressions by hand. We simulated Larch/ Ada attribute functions 
by functions we defined ourselves. We simulated Larch/Ada aggregates sim- 
ilarly. All of this work was performed in accordance with our mathematical 
theory of verification. 

The details of these changes and manual tasks are described below, 

• Restriction to lower case 

Ada identifiers and reserved words are case-independent (RM 2.3[3], RM 
2. 9 [4]). The Ada object obj may be denoted by “OBJ”, “Obj”, “obj”, 
etc. The Ada programmer is free to use any mixture of case desired for 
object identifiers. 

Larch, however, is case sensitive [10]. The Larch/Ada terms “OBJ”, 
“Obj”, and “obj” are, thus, all distinct linguistic entities — only one of 
these terms can canonically represent the value of the Ada object. Early 
in the development of Penelope, we made the all-lower-case form canoni- 
cal. 

So as to maintain a clear relationship between Ada objects and the Larch 
terms that represent their values, we converted all the identifiers appearing 
in Calendar .Utilities to lower case. This change did not affect the Ada 
semantics. 

• Fully expanded expressions 

Penelope does not yet support the USE context clause. When referring 
to types and objects of WITHed packages, it was necessary to write their 
fully expanded names. Thus, we needed to change the references to type 
year .number of package calendar to read “calendar .year_number” . In 
the same vein, we declared and VITHed a package built in so that we 
could refer to the built-in type duration. 

• Constraints and ranges 

Penelope does not yet support range constraints. The integer type defini- 
tions in the original code have therefore been transformed to declarations 
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of unconstrained new integer types. Larch/ Ada predicates for the sorts 
corresponding to these types have been defined so that we can code range 
checking explicitly. 

The names of these functions are the names of the corresponding types 
prefixed with “good.”. Their definitions are taken from the bounds of 
the range in the original Ada text of Calendar-Utilities. We used 
them systematically in the specifications of programs that have formal 
parameters of the original range type, and as conditions on axioms and 
lemmas that have variables of the corresponding sort. Doing so ensured 
that range checking is always part of the correctness condition of the 
verified software. 

For instance, the explicit Larch/Ada IN annotation 
IF good_month(the_month) ; 
takes the place of the implicit constraint check 

1 < thejnonth <12 


for the Ada type Month. 

• Derived types 

Penelope does not yet fully support derived types in Ada. The type mark 11 
of a derived type is today treated as an alias for the parent type instead of 
as an isomorphic copy. This means that Penelope’s typechecking of Ada 
is somewhat too lenient, as it does not guard against improperly mixing 
parent and derived types in an Ada expression. It was part of our task as 
verifiers to take such precautions manually. 

• Type conversion 

Type conversions are not yet supported by Penelope. Its typechecker does, 
however, support the restriction against using names of types as function 
names. Where explicit type conversions appear in the original Ada code, 
therefore, they are rejected by Penelope as illegal function calls. To over- 
come these limitations, we have replaced all explicit type conversions with 
calls to actual functions whose specified effect is to perform the desired 
type coercions. 

The name of a coercion function follows this convention: the name of 
the target type has the suffix M _ize M . Thus a function that coerces to 
type integer is named a integer_ize” 12 . Since the coercion functions 

11 See the Ada RM 3.3.2:2-3 f 3.4 

12 Ada overloading permits as many identically- named functions as required, one for each 
type to be coerced. The typechecker determines which function is intended from the type of 
the argument. 
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are purely auxiliary, no bodies for them are given, only Ada specifications. 
Their Larch/ Ada specifications provide the predicate transformers with all 
of the information that is required to perform the necessary type coercions. 

That constrained types and ranges are not yet supported introduces fur- 
ther complications. There is currently no distinction in Penelope between 
the types integer, natural and positive; consequently, are all the same 
type: the conversion between them is apparent, not real. The “_ize” 
functions for the numeric types thus actually all take integer arguments 
and return integer results under another name. 

We have these pseudo- conversions in the code for two reasons. First, 
we wish to change the text as little as possible. The change in going 
from natural (obj) to naturalize (obj ) is smaller than in going from 
natural (obj) to obj. Second, we express the constraints that must 
hold for the object as Larch/ Ada II specifications on the “ize” func- 
tions. Thus, we specify that the input value to naturalize must be 
non-negative. In fact, we explicitly state all of the constraints on objects 
that Penelope will later infer from their types. 

• Attribute functions 

Penelope does not yet support the automatic generation of attribute func- 
tions, nor is the “tic” (i.e., the character “*”) notation for them acceptable 
syntax. We replaced each function of the form <type_mark > 1 <attribute> 
in the original code by a function named <type jiark>_tic_<attribute>. 
We have added Ada specifications for these functions; the new Ada spec- 
ifications are identical to those defined for the corresponding attribute 
functions. These pseudo-attribute functions have been annotated with 
Larch/ Ada specifications that correctly describe the semantics of the at- 
tribute function by means of axioms that have been entered manually into 
the traits. The entire process is well defined and capable of automation. 

• Aggregates 

Penelope does not yet support aggregate expressions. We circumvented 
this limitation in each case by declaring a temporary object of the result 
type, assigning the appropriate values to its fields, and returning the object 
thus constructed. 

Penelope will someday have aggregate- like constructs in Larch/Ada. Even 
without them, however, we have full expressiveness in Larch/Ada to name 
any (finite) array value. The array-update notation 

Array [index => value] 

denotes the array having value value at index index and agreeing with 
Array at every other index. Repeated application of the array-update 
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notation can be used to denote an array having a chosen value at each 
index. 

To suggest the aggregate- like notation that we will someday implement, 
we declared constant functions on array sorts and updated all of the com- 
ponents of these undetermined constants whenever we wished to name a 
particular array value. One example is the term denoting the array of 
days of the months in an ordinary year: 

month_days_tic [1=>31] [ 2=>28] [ 3=>31] C 4=>30] 

[5=>31] [ 6=>30] [ 7=>31] [ 8=>31] 

[9=>30] [10=>31] Cll=>30] [12=>31] 


• FOR loops 

FOR loops are not yet included in the subset of Ada for which Penelope has 
verification rules. FOR loops in the code have been replaced by WHILE loops 
whose test is that the index variable has reached the upper bound. The 
index variable is initialized to the lower bound by a preceding assignment 
statement and is incremented by an assignment statement at the end of 
the loop body. 

• Aliasing 

Penelope has very conservative checks against improper aliasing; these 
checks reject subprogram calls which would result in certain kinds of pro- 
gram errors 13 , but may also reject subprogram calls that are error-free. In 
particular, Penelope does not allow two components from the same record 
object to appear as actuals for out or in out formal parameters — for 
example, the call 

calendar . split (result . the_year , 
result . the_inonth t 
result . the_day) 

To accommodate the checks, we rewrote the call slightly. The modified 
code calls calendar, split with temporaries in place of the record compo- 
nents and assigns each of the temporaries to the corresponding component 
after the procedure call. 

■ m Exceptions 

The circumstances under which Constraint ^Error would be raised by the 
application of day_name_tic_val are specified in the Larch/ Ada annota- 
tion of that function. 


13 Technically, certain kinds of erroneous executions and incorrect order dependences. 
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Penelope does not yet support Ada restrictions on declaration of excep- 
tions. Instead, Penelope considers an exception to be implicitly introduced 
at its first occurrence in propagation annotations. We removed exception 
declarations to perform this verification. After this change, Penelope is, 
in effect, more lenient than Ada in the declaration of exceptions. We 
therefore ensured that we did not introduce new exceptions. 

• Actual Parameter lists 

Penelope does not yet support named parameter association. We changed 
occurrences in the original code to positional parameter association. This 
change affects only the convenience of the caller, not the correctness of 
the subprogram. 


4.4,2 Results 

Verified Functions We fully verified the functions IsXeapJTear, DaysJTn 
(both Month and Year versions), Konth_0£ (both lumber and lame versions), 
DayXf (Time version), TimeXf (Year, Day version) and PeriocLOf. 

Detected Errors The function DurationJOf contains a programming error 
that was detected first in the specification phase and is discussed in Section 4.3. 
In this verification phase, the error was highlighted by completing the proofs 
for all of the VCs of the program except for one, which can be seen to closely 
correspond to the incorrect expression. 

The goal of the VC, paraphrased, says that the value held by an integer 
variable (TheXnterval .ElapsecLM ill i seconds) is unchanged when it is suc- 
cessively divided, then multiplied by 1000 (using integer arithmetic): 

(the_interval . elapsed_milliseconds/1000)*1000 

the_interval . elapsed_milliseconds 

A well-trained verifier may respond to this clearly unprovable goal by recognizing 
its relation to the RETURI condition ofThe specification and pinpointing the line 
of code with the offending expression. 

Two further errors were actually discovered during the verification process. 
Both errors occur in the function Day_0f (Year, Day). We detected them by 
realizing that we could not prove the VC generated for the loop invariant. The 
two remaining incomplete subproofs correspond to the two errors. 

The function 

Day_of (the.year: year; the.day: year_day) return day_name; 

returns the name day of the week on which day number thejday falls in the 
year the_year. It proceeds by first executing a loop to determine the day of 
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the week on which the_year begins, and then shifting that day of the week by 
thejday (modulo 7). Each step contains an error. 

The loop counter Index runs from year’first+l to the.year, and each 
iteration of the loop should advance the day .name stored in result by either 
one day (if Index is not a leap year) or two days (if it is). The VC for the loop, 
however, is this: 

(IF is_leap_year(the_year) 

THEM (good_day_name (day _name_sort_increment (result f 2)) 

-> 

(day_name_sort_increment (result , 2) 
day_name_oI (index, 1))) 

ELSE (good_day__name (day _name_sort_increment (result , 1)) 

-> 

(day_name_sort_increment (result , 1) 
day _name_of (index, 1)))) 

This is unprovable, because the IF assertion is branching, not on the value of 
index, but on the value of the_year. On checking the IF statement in the body 
of the loop, we find that it incorrectly tests the loop bound instead of the loop 
index; that is, Is_Leap_Year(TheJfear), instead of Is_Leap_Year(Index) . 

The problem with the second step is that it attempts to calculate the shift 
as follows: 

Hatural ( (thejday mod 7) - i) 

If the value of thejday mod 7 is zero, the type conversion to latural will raise 
an exception. The shift should instead be calculated by 

latural ((the_day - 1) mod 7) 

This error was discovered by considering the VC 

0 < (thejday MGD 7) 

AND 

( good_day_name ( 

day_name_sort_increment (result , (thejday MOD 7) - 1) 

) 

-> 

( day_name_sort_increment (result , (the_day MOD 7) - 1) 
day_name_of (the_year , the_day) 

) 


) 


46 


4 A DEMONSTRATION OF THE PENELOPE SYSTEM 


The assertion 0 < (thejday MOD 7) is simply not true, and this directed us 
immediately to the mistaken calculation of the shift. (Note the origin of 0 < 
(the_day MOD 7): it is precisely what must hold in order to guarantee that the 
unwanted constraint error is not raised.) 

The most intriguing thing about these last two errors is that they will not 
invariably lead to incorrect output from the function. Though we will not prove 
it here, the function will in fact return the correct value for the years 1984- 
87, as long as the value of the input parameter The_Day is not congruent to 0 
mod 7. There is at least the possibility that the existence of a problem could go 
undetected through some moderately extensive, but unfortunately chosen, test 
cases. 

Each of the errors described in this section is a local mistake and can be fixed 
with a small change to the program. The near-completeness of the corresponding 
VCs clearly shows that the resulting programs could then be fully verified. 
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4.4.3 Summary of Results 

We specified all eighteen functions of the package CalendarJJtilities using 
Larch/Ada. Of these, we selected thirteen for formal verification. We treated 
eleven of the thirteen completely. 

Of the eleven we treated formally, we verified eight and detected errors in 
three others. Seven functions were not treated formally. 

Our results are in the table below. When two functions share a common 
name, we comment on their arguments enough to distinguish them. 


Function 

Comments 

Verified 

Incorrect Not Treated 

Is-LeapJfear 


• 


Days_In 

(Year) 

• 


Days Jin 

(Month) 

• 


HonthJDf 

(Month Humber) 

• 


Month_Of 

(Month Hame) 

• 


Day J0f 

(Year, Day) 


• 

Day _0f 

(Time) 

• 


TimeJDf 

(Year, Day) 

• 


PeriodJOf 


• 


TimeJDf 

(Time) 


• 

Time_0f 

(Calendar .Time) 


• 

TimeJTmageJDf 



• 

Date_ImageJOf 



• 

ValuejOf 

(Date/Time Strings) 


• 

Duration_Of 



• 

Interval-Df 



• 

ImageJDf 



• 

ValueJDf 

(Interval String) 


• 
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5 Conclusions 

This demonstration of the power and practicability of formal methods in Pene- 
lope was a success. Formal specification in Penelope was useful for analyzing 
the software, both informally and formally. Formal verification gave greater 
confidence in the correctness of most of the package. Where the software was 
incorrect, the errors detected by Penelope could have gone unnoticed in testing. 

This verification effort was the first to use a non-built-in data type exten- 
sively in Penelope. Without the automatic simplification that is provided for 
the built-in types, we found ourselves spending far too much of our time man- 
ually applying simplification directives. Future directions for Penelope should 
include consideration of automatic simplification within user-supplied theories. 

Library-based verification would have been greatly advantageous. Because of 
the sheer bulk of the Ada code within a single buffer, Penelope ran very slowly. 
This problem lends support to our conclusions, drawn before this demonstration, 
that library-based verification is a necessity and validates our efforts in that 
direction. 

Penelope is a useful prototype today for developing correct software. As 
ORA continues to enhance Penelope, it will become a generally useful tool. 
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Appendix A: Related Work 

The field of formal verification began with the work of Hoare [12, 13]. Dijkstra 
and Gries went on to develop and advocate a distinctive style of verification 
based on Hoare ’s ideas. A thorough basic introduction to Dijkstra-Gries style 
verification can be found in Gries [6], The same material is covered more fully 
in Dijkstra [3]. 

A serious obstacle to performing Dijkstra- Gries style verification by hand 
is the crushing work of bookkeeping in verifying actual programs (as opposed 
to textbook exercises). Penelope [8] is an automated assistant that manages 
the details of predicate transformation and proof checking, freeing the user to 
perform the conceptual work of verification. 

Other computerized verification systems include EHDM [2], Gypsy [5], ORA 
Ottawa’s m-EVES [1], and SDVS [15]. 

The Larch [10] system of mathematical specification separates mathematical 
concerns from programming concerns. Significant research has investigated how 
best to specify programs in the Larch system [17]. 
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Appendix B: 


Assertion 


Floyd- Hoare Triple 


Precondition 


Predicate 


Program Semantics 


Sort 


Specification 


Glossary 


A mathematical statement about a program state. 
To make an assertion is to claim that a certain 
predicate is true. 

The triple {tnifui/} S {final} symbolizes that soft- 
ware S transforms state initial into state final . 
The Floyd-Hoare triple is basic to the mathemat- 
ics of program semantics. 

A predicate that must hold on the program state 
before a statement executes if the statement is to 
bring about its intended effect. 

A logical formula such as x > 17; a mathemati- 
cal expression that is either true or false when its 
variables are assigned values. 

Loosely speaking, the behavior of software. Pro- 
gram semantics treats the behavior of a program 
as its meaning. 

The logical category of a mathematical object, 
analogous to a data type. The sort of the mathe- 
matical integers is Int. 

A user-supplied predicate describing the condi- 
tions that are to hold at various points in the ex- 
ecution of a program. 

• Input specifications describe the initial state 
of the program; that is, what must be true 
before the program executes. 

• Output specifications describe the final state 
of the program. The circumstances of both 
normal and exceptional termination can be 
specified. 

• In addition, there are specifications available 
to describe conditions at user-chosen points 
within the program body. 
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Tier One of the two levels of Larch/Ada specification. 

The interface tier is used to specify program be- 
havior mathematically. The mathematical ma- 
chinery for the specification is modularized into 
traits in the mathematical tier. 

Trait A Larch theory module. lYaits encapsulate all 

of the apparatus of a logical theory: the sorts, 
function declarations, axiom, lemmas, and so on. 
An example is the trait for the theory of integer 
arithmetic given on p. 83 of Larch in Five Easy 
Pieces [10]: the sort introduced is Int, a familiar 
axiom is x < (x + 1). 

Note that traits can be built up from other traits, 
just as program modules can call other program 
modules. 

Predicate Transformation A process akin to symbolic execution of a program 

during which the precondition of each statement 
in a program is calculated. 

VC See Verification Condition. 

Verification Condition A formula that must be proved true for a program 

to be proved correct. Loosely speaking, the verifi- 
cation conditions of a program collectively assert 
that the statements of the program act together to 
transform the specified initial program state into 
one of the specified acceptable final states. 

Verification conditions are calculated from speci- 
fications and preconditions. 
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Appendix C: Package Calendar.Utilities 

This appendix shows the full Ada text of the Ada specification and the body of 
the package Cal endar.Ut il i t ies . It differs only by reformatting from the text 
that NASA sent ORA. 

Copyright Grady Booch, part of the Ada Booch components 1984-1992. 


C.l Package Specification of Cadendar .Utilities 

with Calendar; 

package Calendar_Utilities is 


type Year 

is new Calendar . Year_Iuraber ; 

type Month 

is range 1 

.. 12; 

type Day 

is range 1 

..31; 

type Hour 

is range 0 

.. 23; 

type Minute 

is rainge 0 

.. 69; 

type Second 

is range 0 

.. 69; 

type Millisecond 

is range 0 

.. 999; 


type Time is 
record 

The_Year : 

The_Month : 

The_Day : 

The_Hour : 

The_Minute 
The.Second : 

The_Millisecond : 
end record; 


Year ; 

Month ; 

Day; 

Hour; 

Minute; 

Second; 

Millisecond; 


type Interval is 
record 

Elapsed_Days 
Elapsed_Hours 
Elapsed_Minutes 
Elapsed.Seconds 
Elapsed.Milliseconds 
end record; 


Vatural ; 
Hour; 

Minute; 

Second; 

Millisecond; 


type Year_Day is range 1 .. 366; 


type Month_Name is (January, February, March, 
April, May, June, 
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July, August, September, 

October, lovember, December); 
type Day_Mame is (Monday, Tuesday, Wednesday, 

Thursday, Friday, Saturday, Sunday); 

type Period is (AM, PH); 

type Time_Format is (Full, — 01:21:06:30 PM 

Military); — 13:21:06:30 

type Date_Format is (Full, — FEBRUARY 27, 1955 

Month_Day_Year) ; — 02/27/55 

function Is_Leap_Year (The_Year : in Year) 
return Boolean; 

function Days_In (The_Year : in Year) 

return Year.Day; 

function Days_In (The_Month : in Month; 

The_Year : in Year) 

return Day; 

function Month_0f (The_Month : in Month) 

return Month_Name; 

function Month_0f (The_Month : in Month_Iame) 

return Month; 

function Day_0f (The_Year : in Year; 

The_Day : in Year_Day) 

return Day_Name; 

function Day_0f (The_Time : in Time) 

return Year_Day; 

function Time_0f (The_Year : in Year; 

The_Day : in Year_Day) 

return Time; 

function Period_0f (TheJTime : in Time) 
return Period; 

function Time.Of (TheJTime : in Time) 

return Cal endar .Time ; 

function Time.Of (TheJTime : in Calendar .Time) 

return Time; 

function Time_lmage_0f (The_Time : in Time; 

Time.Form : in Time_Format := Full) 

return String; 

function Date_lmage_0f (TheJTime : in Time; 

DateJForm : in Date_Format := Full) 


return String; 
function Value_0f 


(The_Date : in String; 
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TheJTime : in String; 

Date_Form : in Date_Format := Full; 
Time^Form : in Time ..Format := Full) 

return Time; 


function Duration_Of 
return Duration; 
function Interval_Of 
return Interval; 
function Image.Of 
return String; 
function Value_0f 
return Interval; 


(The.Interval 

(The_Duration 

(The.Interval 

(The.Interval 


in Interval) 
in Duration) 
in Interval) 
in String) 


Lexical.Error : exception; 
end Calendar .Utilities ; 


C.2 Package Body of CalendarJJtilities 

with Integer_Utiliti.es, 

Fixed_Point_JJtilities , 

String.Utilities ; 

package body Calendar.Utilities is 

type Month_Day is array (Month) of Day; 


Century_Of f set 

Days.Per.Year 

Days.Per.Month 


First.Day 

Seconds_Per_Minute 

Seconds.Per.Hour 


constant 

: = 

1900; 

constant 

: = 

365 

» 

constant Month.Day 

: = 

(1 

=> 31, 



2 

=> 28, 



3 

=> 31, 



4 

=> 30, 



5 

=> 31, 



6 

=> 30, 



7 

=> 31, 



8 

=> 31, 



9 

=> 30, 



10 

=> 31, 



11 

=> 30, 



12 

=> 31); 

constant Day.Iame 

: = 

Tuesday; 

constant 

: = 

60; 


constant 

: = 
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60 * Seconds.Per.Minute; 
Seconds. Per.Day : constant * = 

24 * Seconds.Per.Hour ; 


Milliseconds.Per.Second : constant := 1000; 

Soon : constant Hour := 12; 

Time .Separator : constant Character := 9 : 9 ; 

Date.Separator : constant Character := 9 / 9 \ 

Blank : constfiuit Character :* 1 1 ; 

Comma : constant Character : = 9 , 9 ; 

Zero : constant Character := *0*; 


package latural.Ut ilities is new Integer.Ut ilities 

(lumber => Hatural); 

package Duration.Ut ilities is new Fixed.Point.Utilities 

(lumber => Duration) ; 

function Image.Of (The.Fumber : in latural) return String is 
begin 

if The.Humber < 10 then 

return String_Utilities .Replaced 

(The. Character => Blank, 

With.The.Character => Zero, 

In.The.String => 

Natural.Ut ilities . Image.Of (The.Humber) ) ; 

else 

return String.Ut ilities . Stripped.Leading 
(The .Character => Blank, 

From.The.String => 

latural.Ut ilities . Image.Of (The.Humber) ) ; 

end if; 
end Image.Of ; 

function Is.Leap.Year (The.Year : in Year) return Boolean is 
begin 

if The. Year mod 100 = 0 then 

return (The .Year mod 400 = 0) ; 

else 

return (The.Year mod 4=0); 
end if; 

end Is.Leap.Year; 

function Days. In (The.Year : in Year) return Year.Day is 
begin 
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if Is_Leap_Year(The_Yeax) then 
return (Days_Per_Year + 1); 

else 

return Days_Per_Year; 
end if; 
end Days_In; 

function Days_In (The.Month : in Month; 

The.Year : in Year) return Day is 

begin 

if (The_Month = Month_Iafie'Pos (February) + 1) and then 
Is_Leap_Year (The_Year) then 

return (Day s.Per.MonthCMonth.Iame’Pos (February) + 1) 

+ i); 

else 

return Days_Per_Month(The_Month) ; 
end if; 
end Days_In; 

function Month_Of (The_Month : in Month) return Month.Hame is 
begin 

return Month^Iame 9 Val(The_Month - 1); 
end Month^Of; 

function Honth_Of (The_Month : in Honth.Vame) return Month is 
begin 

return (Month_Iame *Pos(The_Month) + 1); 
end Month__Of; 

function Day_Of (TheJYear : in Year; 

The_Day ; in Year_Day) return Day_Iame is 
Result : Day.Iame := First.Day; 
procedure Increment (The_Day : in out Day.Vame; 

Offset : in Vatural := 1) is 
— This moves you through day names by offset places. 

— Instead of using MOD, it uses exception when you pass 
— Sunday 
begin 

The.Day := Day_Iame 1 Val(Day_Iame , Pos(The_Day) 

+ Offset); 

exception 

when Constraint_Error => 

The_Day : = Day^ame* Val(Day_Iame , Pos(The_Day) 

+ Offset - 7); 
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end Increment; 
begin 

for Index in (Year’First + 1) . . The.Year loop 
if I s_Leap_Year( The.Year) then 

Increment (Result , Offset s > 2); 

else 

Increment (Result) ; 
end if ; 
end loop; 

— this uses 365/366 REH 7 and goes through the years, 

— then does days 
Increment (Result , 

Offset => Natural (((The.Day mod 7) - 1))); 
return Result; 
end Day_Of ; 

function Day.Of (The.Time : in Time) return Year.Day is 
Result : Natural := 0; 
begin 

for Index in Month’First .. (The_Ti«e.Tlie_Honth - 1) loop 
Result := Result + 

Natural (Days_In(Index , The.Time . The.Year) ) ; 

end loop; 

return Year.Day (Result + Natural (The.Time .The.Day) ) ; 
end Day_0f; 

function Time_0f (The.Year : in Year; 

The.Day : in Year.Day) return Time is 
Result : Year_Day := The_Day; 
begin 

for Index in Month’First . . Month’ Last loop 

if Result <= Year.Day (Days_In(Index, The.Year)) then 
return Time’ ( 

The_Year => The .Year, 

The.Month => Index, 

The.Day => Day(Result), 

The.Hour => Hour' First, 

The.Minute => Minute’First , 

The.Second => Second’First , 

The.Millisecond => Millisecond’First) ; 

else 

Result := 

Result - Year.Day (Days. In (Index, The.Year)); 
end if; 
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end loop; 

raise Lexical. Error; 
end Time.Of; 

function Period.Of (The.Time : in Tine) return Period is 
begin 

if The_Time . The_Hour >= loon then 
return PM; 

else 

return AM; 
end if; 

end Period.Of; 

function Time.Of (The.Time : in Time) return Calendar . Time is 
begin 

return Calendar . Time.Of 
(Year => 

Calendar . Year.Iumber (The.Time . The _ Year) , 

Month => 

Calendar . Mont h. lumber (The .Time . The.Month) , 

Day => 

Calendar . Day .lumber (The.Time . The.Day ) , 

Seconds => 

Calendar . Day .Duration 

( Integer (The.Time .The.Hour) * 
Seconds.Per.Hour) + 

Calendar . Day.Duration 

( Integer (The.Time . The.Minut e) * 
Seconds.Per.Minute) + 

Calendar . Day.Durat ion( 

The.Time. The.Second) + 

Calendar * Day. Duration 
(The.Time .The.Millisecond / 
Milliseconds.Per.Second) ) ; 

(The.Time : in Calendar. Time) return Time is 
: Time; 

Total.Duration : Calendar .Day .Duration; 

Seconds : latural; 

begin 

Calendar . Split (The.Time , 

Year => 

Calendar . Year. lumber (Result . The.Year ) , 


end Time.Of; 

function Time.Of 
Result 
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Month => 

Calendar . Month.Iumber (Result .The.Month) , 
Day => 

Calendar . Day .lumber (Result . The.Day ) , 
Seconds => 

Total.Duration) ; 

Seconds := Duration.Utilities .Floor (Total.Durat ion) ; 
Result . The.Hour := Hour(Seconds / Seconds .Per.Hour) ; 
Seconds Seconds mod Seconds .Per.Hour; 

Result .The.Minute : s 

Minute (Seconds / Seconds .Per .Minute) ; 

Result .The.Second := 

Second(Seconds mod Seconds.Per .Minute) ; 

Result .The.Millisecond := 

Millisecond 

(Duration_Utilities.Real.Part 

(Total.Duration) * Milliseconds.Per.Second) ; 
return Result; 
end Time.Of ; 

function Time.Image.Of (The .Time ; in Time; 

Time .Form ; in Time .Format := Full) 

return String is 
begin 

case Time.Form is 

when Full => 

if The_Time.The_Hour > loon then 
return ( 

Image.Of (Iatural( 

The.Time . The.Hour - 12)) ft 
Time_Separator ft 

Image.Of (latural (The.Time . The.Minute) ) ft 
Time .Separator k 

Image.Of (Satural (The. Time . The.Second) ) k 
Time.Separator k 
Image.Of (latural ( 

The.Time.The.Millisecond) / 10) k 

" PM M ); 

else 

return ( 

Image.Of ( Batural (The.Time . The.Hour ) ) t 
Time.Separator k 

Image.Of (latural (The.Time . The.Minut e) ) ft 
Time.Separator ft 
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Image.Of (latural (The.Time . The.Second) ) ft 
Time.Separator ft 
Image.Of (latural ( 

The_Time.The_Millisecond) / 10) ft 

" AM M ); 


end if; 

when Military => 

return (Image_Of(Iatural(The_Time.The_Hour)) ft 
Time.Separator ft 

Image.Of (latural (The.Time . The.Minut e ) ) ft 
Time.Separator ft 

Image.Of (latural (The.Time . The.Second) ) ft 
Time.Separator ft 
Image.Of (latural ( 
The.Time.The.Hillisecond) / 10)); 

end case; 


end Time.Image.Qf ; 


function Date.Image.Of (The.Time : in Time; 

Date.Form : in Date.Format := Full) 


return String is 
begin 

case Date.Form is 

when Full => 

return (Month.Iame 1 Image (Honth.Vame * Val ( 
TheJTime.TheJfonth - 1)) ft 
latural.Utilities . Image. Of ( 
latural (The.Time.The.Day)) ft 
Comma ft 

latural.Utilities . Image^Of 

(latural(The_Time. The. Year))) ; 
when Mont h_Day_ Year => 

return (Image.Of (Integer (TheJTime.The.Honth)) ft 


end case; 

end Date.Image.Of ; 


Date.Separator ft 

Image.Of ^integer(The.Time .The.Day) ) ft 
Date.Separator ft 

Image.Of ( Int eger (The.Time .The. Year) ) 
(4 .. 5 )); 


function Value.Of (The.Date 
The .Time 
Date_Form 


in String; 
in String; 

in Date.Format := Full; 
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Time.Form : in Time.Format := Full) 

return Time is 

Result : Time; 

Left.Index : Positive; 

Right. Index : Positive; 
begin 

case Date.Form is 

when Full => 

Right.Index := String_Utilities.Location.Of 
(The .Character => Blank, 
In.The.String => The.Date) ; 
Result .The.Month := Month (Month.Iame ’Pos 

(Month.Iame 1 Value 
(The.Date( 

The.Date 1 Fir st . . 
(Right .Index - 1)))) 

+ i); 

Left. Index := Right.Index + 1; 

Right. Index := String.Utilities .Location.Of 
(The.Character => Comma, 
In.The.String => 

The.Date ( 

Left.Index. .The.Date 'Last) ) ; 
Result .The.Day := Daydatural.Utilities .Value.Of 
(The.Date 

(Left.Index . . 

(Right.Index - 1)))); 
Left.Index := Right.Index + 1; 

Result. The.Year := Year (latural.Util it ies .Value.Of 

(The.Date 

(Left.Index . . 
The.Date'Last))) ; 

when Honth.Day.Year => 

Right.Index : = String.Utilities .Location.Of 

(The.Character => Date.Separator, 
In.The.String => The.Date) ; 
Result .The.Month := 

Month (Natural.Util it ies .Value.Of 
(The.Date 

(The.Date 1 First .. (Right.Index - i)))); 
Left.Index := Right.Index + 1; 

Right.Index := String.Utilities .Location.Of 

(The.Character => Date.Separator, 
In.The.String => 
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The.Date (Left .Index . . 

The.Date * Last) ) ; 

Result .The.Day := Daydatural.Utilities . Value.Of 
(The.Date 

(Left.Index . . 

(Right.Index - 1)))); 
Left.Index := Right.Index + i; 

Result .The_Year : = Year(Iatural_Utilities . Value.Of 

(The.Date 

(Left.Index . . 
The.Date’ Last)) + 
MaturalCCentury .Offset)) ; 

end case; 

Right.Index String.Utilities .Location.Of 

(The.Character => Tiae.Separator, 
In.The.String => The.Tiae) ; 

Result .The.Hour := Hour (latural.Utilities .Value.Of 

(The.Time 

(The.Tiae ’First . . 

(Right .Index - 1)))); 

Left. Index := Right. Index + 1; 

Right. Index := String.Utilities .Location.Of 

(The.Character => Tiae.Separator, 
In.The.String => 

The.Tiae (Left. Index. . The.Tiae’ Last ) ) ; 
Result .The.Hinute := Minute (latural.Utilities .Value.Of 

(The.Tiae 

(Left.Index . . 

(Right. Index - 1)))); 

Left.Index := Right.Index ♦ i; 

Right.Index := String.Utilities. Location.Of 

(The.Character => Tiae.Separator, 
In.The.String => 

The.Tiae (Left.Index. .The.Tiae 'Last)) ; 
Result .The.Second := Second(Iatural.Utilities .Value.Of 

(The.Tiae 

(Left.Index . . 

(Right.Index - 1)))); 

Left.Index := Right.Index + 1; 
case Tiae.Fora is 
when Full => 

Right.Index := String.Utilities .Location.Of 
(The.Character => Blank, 
In.The.String => 
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The.Time(Left_Index . . 
The.Time’Last)) ; 

Result .The.Millisecond := 

! Millisecond(Hatural.Utilities . Value.Of 

(The.Time (Left. Index .. (Right. Index - 1)))); 
Left.Index := Right. Index + 1; 
if Period 1 Value (The.Tiae(Left_Index . . 

The.Time’Last)) = PM 

then 

if Result .The.Hour /= loon then 
Result . The.Hour := 

Result .The.Hour + loon; 
end if; 
end if ; 

when Military => 

Result .The.Millisecond := 

Mill is econd(Matural_Utilities .Value.Of 

(The.Time (Left. Index .. The.Time ’Last) ) ) ; 

end case; 
return Result; 
exception 

when Constraint.Error => 
raise Lexical. Error; 
end Value.Of ; 

function Duration.Gf (The. Interval : in Interval) 

return Duration is 

begin 

return (Duration(Integer(The_Interval.Elapsed_Days) 

* Seconds.Per.Day) + 

Dur at ion ( Int eger (The.Int erval . Elaps ed.Hour s ) 

* Seconds.Per.Hour) 

Dur at ion ( Int eger (The. Int erval . Elaps ed.M inut e s ) 

* Seconds.Per.Minute) + 

Duration (The. Int erval . Elaps ed.Seconds) + 

Duration (The.Int erval . Elaps ed.Milliseconds 

/ 1000 )); 

end Duration.Gf ; 

function Interval.Of (The.Duration : in Duration) 
return Interval is 

Result : Interval; 

The.Seconds : Duration := The.Duration; 
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begin 

Result . Elapsed_Days := Durat ion_Util it ies .Floor 

(The.Seconds / Seconds_Per_Day) ; 

The_Seconds := 

The_Seconds - 

Durat ion (Integer (Result . Elapsed_Days) 

* Seconds_Per_Day) ; 

Result .Elaps ed.Hours := 

Hour (Duration_Utilities .Floor 

(The_Seconds / Seconds_Per_Hour) ) ; 

The_Seconds := 

The_Seconds - 

Duration ( Int eger ( Result . Elaps ed_Hour s ) 

* Seconds_Per_Hour) ; 

Result . Elaps ed_Kinutes 

Minute (Duration_Utilities . Floor 

(The^Seconds / Seconds_Per_Minute)) ; 

The_Seconds : = 

The_Seconds - 

Durat ion( Integer (Result . Elapsed.Minutes) 

* Seconds_Per_Minute) ; 

Result . Elapsed_Seconds := 

Second(Duration_Utilities .Floor 

(The_Seconds)) ; 

The_Seconds : = 

The_Seconds - Durat ion(Result . Elapsed_Seconds) ; 

Result .Elapsed_Milliseconds := 

Millisecond 

(Duration_Utilities.Floor(Tlie_Seconds * 1000)); 
return Result ; 
end Interval_0f; 

function lmage_0f (The_ Interval : in Interval) 

return String is 

begin 

return (lraage_0f (latural (The_Interval, Elaps ed_Days)) ft 
Time_Separator ft 

lmage_0f (Natural (The_Interval . Elaps ed^Hours) ) ft 
Time_Separator ft 

lmage_0f (Iatural(The_Interval.Elapsed_Minutes) ) ft 
Time. Separator ft 

lmage_0f (Matural (The_Interval . Elapsed.Seconds) ) ft 
Time_Separator ft 
Image^Of (latural ( 
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The .Interval . Elapsed.Milliseconds) ) ) ; 

end Image.Of; 

function Value.Of (The. Interval : in String) 
return Interval is 

Result : Interval; 

Left. Index ; Positive; 

Right. Index : Positive; 
begin 

Right.Index := String_Utilities.Location.Of 

(The.Character => Time.Separator , 
In.The.String => The. Interval) ; 

Result .Elapsed.Days := latural.Utilities . Value.Of 

(The. Interval 

(The.Interval' First .. 
(Right.Index - 1))); 

Left. Index := Right.Index + 1; 

Right.Index := String.Utilities .Location.Of 

(The.Character => Time.Separator, 
In.The.String => 

The. Interval (Left. Index . . 

The. Interval* Last) ) ; 

Result .Elapsed.Hours := Hour (latural.Utilities .Value.Of 

(The.Interval 
(Left.Index . . 

(Right.Index - 1)))); 
Left.Index := Right.Index + 1; 

Right.Index := String.Utilities .Location_Of 

(The.Character => Time.Separator, 
In.The.String => 

The.Interval (Left.Index . . 

The.Interval 'Last)) ; 

Result .Elapsed.Minutes := 

Minute (latural.Utilities. Value.Of 
(The.Interval 

(Left.Index .. (Right.Index - 1)))); 

Left.Index := Right.Index + 1; 

Right.Index := String.Utilities .Location.Of 

(The.Character => Time.Separator, 
In.The.String => 

The_Interval(Left_Index . . 

The.Interval' Last)) ; 

Result .Elapsed.Seconds := 

Second(Hatural_Utilities . Value.Of 
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(The. Interval 

(Left. Index .. (Right.Index - 1)))); 
Left. Index := Right.Index + 1; 

Result . Elapsed.Nilliseconds : = 

Millisecond 

(Hatural.Utilities . Value.Of 
(The.Interval 

(Left. Index .. The.Interval’Last))) ; 
return Result; 
exception 

when Constraint .Error => 
raise Lexical. Error; 
end Value.Of; 


end Calendar.Utilities ; 
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Appendix D: Package Calendar 

This appendix shows the Calendar package of the Ada Reference Manual. 

Copyright 1980, 1982, 1983 owned by the United States Government as 
represented by the Under Secretary of Defense, Research and Engineering. 

package calendar is 
type time is private; 

subtype year.number is integer range 1901 . . 2099; 

subtype month.number is integer range 1 . . 12; 

subtype day.number is integer range 1 . . 31; 

subtype day .duration is duration range 0.0 .. 86.400.0; 

function clock return time; 

function year (date : time) return y e air. numb er ; 

function month (date : time) return month.number ; 

function day (date : time) return day.number; 

function seconds (date : time) return day .duration; 

procedure split (date ; in time; 

year : out year.number; 

month : out month.number; 

day : out day.number; 

seconds : out day .duration) ; 

function time.of (year : year.number; 

month : month.number; 

day : day.number ; 

seconds : day .duration := 0.0) return time; 

function ,, +" (left : time; right: duration) return time; 

function "+" (left : duration; right: time ) return time; 

function M - ,# (left ; time; right: duration) return time; 

function M - M (left : time; right: time ) 

return duration; 

function ,, < M (left, right : time) return boolean; 

function "<=" (left, right : time) return boolean; 

function ">" (left, right : time) return boolean; 

function ,, >= M (left, right : time) return boolean; 


time error : exception; 
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— can be raised by time_of f "+" and 


private 

— implementation-dependent 
end; 
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Appendix E: Full Output from the Penelope 

Verification 

Portions of this text are copyright United States Government as represented by 
the Under Secretary of Defense, Research and Engineering. Portions of this text 
are copyright Grady Booch, part of the Ada Booch components 1984-1992. 

— ■ Verification status: lot verified 

(21 VCs generated; 2 VCs hidden; 16 VCs proved) 

TRAIT Z IS 
DECLARES 
IITRODUCES 

Int_identity : Int -> Int; 

AXIOMS : FORALL [n : Int] 

Int_identity : (Int_identity (n)=n) ; 

END AXIOMS; 

LEMMAS: FORALL [a: Int, m:Int, ml: Int, m2: Int] 
mod_lower: ((m>0)->(0<=(a MOD m))); 
mod_upper: ((m>0)->((a MOD m)<m)); 
mod_ident : (((0<=a) AND (a<m))->((a MOD m)=a)); 
mod_trans it ive : ( 

( 

( ( (ml/=0) AND (m2/=0) ) AND ((ml MOD m2)=0)) 

AND 

((a MOD ml)=0)) 

-> 

((a MOD m2)=0) ) ; 

— I mod_subtract : ( 

( ( (m>0) AND (m<=a) ) AND (a<=((2*m)-l))) 

-> 

((a MOD m)=(a-m) )) ; 

div_upper : (((0<=a) AND (a<m))->((a/m)=0)) ; 

END LEMMAS; 

TRAIT fixed_point IS 
DECLARES 

SORT fixnum IS AnyRecordSort ; 

IITRODUCES 

good_fixnum: fixnum -> Bool; 
abstract; fixnum -> Rational; 
pair: Int, Int -> fixnum; 

Int_to_f ixnum: Int -> fixnum; 

,, * H : fixnum, fixnum -> fixnum; 

M * M : fixnum, Int -> fixnum; 

Int, fixnum -> fixnum; 
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M ^.11 . 
#I_M . 

M <=*' 
If ^ II • 
»l^ = H 


"/" : fixnum, fixnua -> fixnua; 

M / M : fixnua, Int -> fixnum; 

f ixnum, fixnua -> fixnum; 
fixnum, fixnum -> fixnum; 
fixnum, fixnua -> Bool; 
fixnum, fixnua -> Bool; 
fixnua, fixnua -> Bool; 
fixnua, fixnua -> Bool; 
lonZero: fixnua -> Bool; 

IntegerPart: fixnua -> Int; 

RealPart: fixnua -> fixnua; 

Floor: fixnua -> Int; 

Ceiling: fixnua -> Int; 
fixnua_abs: fixnua -> fixnua; 

AXIOMS: FORALL [m: fixnua, n:fixnua, i:Int, j: 
good_f ixnum: (good_f ixnum (m)=(m.denom>0) ) ; 
concrete_equality : ( 

((m.numer=n. nuaer) AID (m.denora=n .denoa) ) 


Int] 


-> 


(m=n) ) ; 

— | abstract_equality : ( 

( 

(good_f ixnum(a) AID good_f ixnum (n)) 

AID 

( (m . numer*n , denoa) =Int_ident ity ( (m . denom*n . nuaer) ) ) ) 

-> 

(abstract (a) =abstract (n) ) ) ; 

— I pair^nuaer: (pair(i, j).numer=i); 

— I pair_denom: (pair(i, j).denom=j); 

— I Int_to_f ixnum: (Int_to_f ixnum(i)=pair(i, 1)); 

— I times_ff _nuaer : ( 

(good_f ixnum(m) AID good_f ixnua(n) ) 

-> 

( (m*n) . numer= Int_ ident ity ( (m , nuaer *n . nuaer) ) ) ) ; 

— I times_ff_denoa: ( 

(good_f ixnua(m) AID good_f ixnum(n)) 

-> 

( (m*n) . denoa=Int_ident ity ( (a . denom*n . denom) ) ) ) ; 

— I times_f i_numer: ( 

good_f ixnua (a) 

-> 

((m*i) .numer=Int_identity((m.numer*i)))) ; 

— I tiaes_f i_denoa: (good.f ixnum (m)->((a*i) .denom=m. denoa) ) ; 

— I times_if _nuaer: ( 
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good_i ixnum(m) 

-> 

((i*m) . numer=Int_identity ( (i*m . numer) ) ) ) ; 

— I times_il..denom: (good_fixnum(m)->((i*m) ,denom=m. denom) ) ; 
— | divides_f*_numer: ( 

((good_l ixnum(m) AID good_lixnum(n)) AMD MonZero(n)) 

-> 

( (m/n) . numer= Incident ity ( (» . numer*n . denom) ) ) ) ; 

— I divides_lf _denom: ( 

((good_lixnum(m) AID good_f ixnum(n)) AID lonZero(n)) 

-> 

( (m/n) . denom= Int _ ident it y ( (m . denom*n . numer) ) ) ) ; 

— I divides_li_numer: ( 

(good_f ixnum(m) AID (i/=0)) 

-> 

( (m/ i ) . numer=m . numer ) ) ; 

— I divides_ii_denom: ( 

(good_lixnum(m) AID (i/=0)) 

-> 

( (m/i) . denom=Int_identity ( (m . denom+i) ) ) ) ; 

— I plus_fi_numer: ( 

(good_f ixnum(m) AID good_f ixnum(n)) 

-> 

( 

(m+n) .numer 

Int_ident ity ( ( (m . numer *n . denom) + (n . numer*m . denom) ) ) ) ) ; 
— | plus_ff_denom: ( 

(good_f ixnum(m) AID good_f ixnum(n)) 

-> 

( (m+n) . denom=Int_ident ity ( (m. denom*n . denom) ) ) ) ; 

— I minus.ff _numer: ( 

(good_f ixnum(m) AID good.f ixnum(n)) 

-> 

( 

(m-n) .numer 

Int_ident ity ( ( (m . numer+n . denom) - (n . numer*m . denom) ) ) ) ) ; 

— I minus_fi_denom: ( 

(good.f ixnum(m) AID good.f ixnum(n)) 

-> 

( (m-n) . denom=Int _ ident it y ( (m . denom*n . denom) ) ) ) ; 

— I iixnum_lt: ( 

(good_f ixnum(m) AID good.f ixnum(n)) 
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-> 

( 

(m<n) 

( 

Int.ident ity ( (m . numer*n . denom) ) 

< 

Int.identity ( (n. numer*m. denom) ) ) ) ); 

— I fixnum.le: ( 

(good.f ixnum(m) AID good_lixnum(n)) 

-> 

( 

(m<=n) 

( 

Int_ identity ( (m . numer*n . denom) ) 

<= 

Int .ident ity ( (n . mimer *m . denom) ) ) ) ) ; 

— I fixnum.gt: ( 

(good.f ixnum(m) AID good.f ixnum(n) ) 

-> 

( 

(m>n) 

( 

Int _ ident ity ( (m . numer *n . denom) ) 

> . ... ... 

Int_identity( (n.numer*m. denom) )))) ; 

— I fixnum.ge: ( 

(good.f ixmim(m) AID good.! ixnum(n)) 

-> 

( 

(m>=n) 

( 

Int.ident ity ( (m . numer*n . denom) ) 

>= 

Int.ident ity ( (n . numer*m . denom) ) ) ) ) ; 

— I IntegerPart: ( 

good_lixnum(o) 

-> 

(IntegerPart (n)=Int .identity ( (n . numei/n . denom) ) ) ) ; 

— I Real Part : ( 

good.lixnum(m) 
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-> 

(RealPart (m) -t iinum_abs ( (m-Int_to_f ixnum( Integer Part (n) ) ) ) ) ) ; 

— I Floor: ( 

good.f ixnum(m) 

-> 

( 

Floor(m) 

Int_identity( 

( 

IF ( (m. mimer<0) AND ((m.numer MOD m.denom)/=0)) 

THEM ( (m . numer / m . denom ) -1 ) 

ELSE (m.numer/m.denom))))) ; 

— I fixnum.abs: ( 

good.f ixnum(m) 

-> 

( 

f ixnum.abs(m) 

(IF (m<Int_to_l ixnum(O) ) THEM ((-l)*m) ELSE m))); 

--I END AXIOMS; 

— I LEMMAS: FORALL [m:fixnum, n:lixnum, p:lixnum f i:Int, 
nl:Int, dl:Int, n2:Int, d2:Int] 

— I good ixnum_real_part : ( 

good.f ixnum(m) 

-> 

good.! ixnum (RealPart (m) ) ) ; 

— I concrete.equality.pair : (FORALL nl:Int, dl:Int, n2:Int, 
d2:Int: :(((nl*d2)=(n2*dl))->(pair(nl, dl)=pair(n2, d2)))); 

— 1 floorl: ((Int.to.i ixnum(0)<=m)->(0<=Floor(a))) ; 

— I pair.plus: ( 

(pair(nl , dl)+pair(n2, d2)) 

pair((Int_identity((nl*d2))+Int_identity((n2*dl))) , 

(dl*d2))) ; 

— I pair.minns : ( 

(pair(nl, dl)-pair(n2, d2)) 

pair((Int_identity((nl*d2))-Int_identity((n2*dl))) , 

(dl+d2))); 

— I divides.pi: (FORALL n:Int, d:Int, 

i : Int : : ( ((d/=0) AND (i/=0))->((pair(n, d)/i)=pair(n, (d^i) ) ) ) ) ; 
— | END LEMMAS; 

— I TRAIT sort .names IS 
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— I DECLARES 

— I SORT calendar .time.sort IS Int; 

— I SORT century IS (twentieth, twentyf irst) ; 

— I SORT years IS Int; 

— I SORT months IS Int; 

— I SORT year .days IS Int; 

— I SORT month_days IS Int; 

— I SORT absolute.days IS Int; 

— I SORT hours IS Int; 

— I SORT minutes IS Int; 

— I SORT seconds IS Int; 

— I SORT milliseconds IS Int; 

— I SORT time.sort IS AnyRecordSort ; 

— I SORT duration.sort IS fixnum; 

— I SORT month.name.sort IS (January, February, March, April, 

May, June, July, August, September, October, lovember, December); 

— I SORT day.name.sort IS (Monday, Tuesday, Wednesday, Thursday, 
Friday, Saturday, Sunday); 

— i SORT period.sort IS (am, pm); 

— I SORT time .format .sort IS (full, military); 

— I SORT date.format.sort IS (full, month.day.year) ; 

— I SORT interval_sort IS AnyRecordSort; 

— I SORT catu IS Int; 

— I IITRODUCES 

— 1 month.name.sort.tic.pos : month.name.sort -> Int; 

— I month.name.sort .tic.val: Int -> month.name.sort ; 

— I good_day_name: day.name.sort -> Bool; 

— I day .name. sort.tic.pos: day_name_sort -> Int; 

— I day.name.sort. tic.val: Int -> day.name.sort; 

— I day.name.sort. increment : day.name.sort, Int -> day.name.sort; 

— I milliseconds.tic.f irst : -> milliseconds; 

— I seconds.tic.first : -> seconds; 

— I minutes.tic.f irst : -> minutes; 

— I hours.tic.f irst : -> hours; 

— I years.tic.first : -> years; 

— I months.tic.f irst : -> months; 

— I months.tic.last : ~> months; 

— I month.name.sort .tic.f irst : -> month.name.sort ; 

— I month.name_sort_tic.last: -> month.name.sort; 

— I time.sort .tic: -> time.sort; 

— I month_days_tic; -> month.days ; 

— I extract.year : cal endar.time. sort -> years; 

— I extract_month : calendar. time, sort -> months; 

— 4 extract.day: calendar .time.sort -> month.days; 
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extract .duration : calendar.time.sort -> duration. sort; 
seconds.to.duration: seconds -> duration. sort; 

**+«: calendar.time.sort, duration.sort -> calendar.time.sort; 
m-h; calendar.time.sort , duration_sort -> calendar.time.sort ; 
calendar.time.sort.identity: 

r. ^i ondar time sort -> cal endar. timers ort; 
duration.sort .identity: duration.sort -> duration.sort; 
good.duration: duration.sort — > Bool; 
good_day: absolute ..days -> Bool; 
good.hour: hours -> Bool; 
good_minute: minutes -> Bool; 
good.second: seconds -> Bool; 
good.millisecond: milliseconds -> Bool; 
good. interval: interval.sort -> Bool; 

AXIOMS: FORALL [the. duration: duration. sort , n:Int, 
the.day.name : day .name. sort , offset : Int , 
the. interval : interval. sort , the.day : absolute.days , 
the.hour : hours , the.minute : minutes , the. second: seconds, 
the.millisecond: milliseconds] 

months.tic. first : (months_tic_first=l) ; 
months.tic.last : (months.tic. last = 12) ; 

month.pos.january : (month.name.sort.tic.pos (January) =0) ; 
month.pos.f ebruary : (month.name.sort.tic.pos (February) =1) ; 
month.pos.march : (month_name.sort-tic.pos (March) =2) ; 
month.pos.april : (month.name.sort.tic.pos (April) ^) ; 
month.pos.may : (month.name.sort.tic.pos (May) =4) ; 
month.pos.june : (month.name.sort.tic.pos ( June) =6) ; 
month.pos.july : (month.name.sort.tic.pos(July) s 6) ; 
month_pos.augu8t : (month.name.sort.tic.pos (August) =7) ; 
month.pos.s ept ember : (month.name.sort.tic.pos (September) ^J) ; 
month.pos.october: (month.name.sort.tic.pos (October) =3) ; 
month.pos.nov ember : (month_name_sort_tic_pos(Iovember)=10) ; 
month.pos.de c ember : (month.name.sort.tic.pos (December) =11) ; 
month.val.O : ( mon t h.name. s or t_tic.val(0)= January) ; 
month. val.l : (month_name.sort.tic.val(l)=February) ; 
month.val.2: (month.name_sort.tic.val (2) =March) ; 
month.val.3: (month_name_sort.tic.val (3) =April) ; 
month_val_4: (month.name_sort.tic.val(4)=May) ; 
month.val.5 : (month.name. sort .tic.val(£)= June) ; 
month.val.6: (month.name_sort_tic.val(6)=July) ; 
month.val.7: (month.name. sort.tic.val (7 )= August) ; 
month_val_8 : (month.name.sort.tic_val(8)=September) ; 
month. val_9: (month_name_sort_tic_val(9)=0ctober) ; 

month.val.10: (month_name.sort.tic.val(10)=Iovember) ; 
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[ month_val_ll : (month_name_sort. < .tic_val(ll)=D6C6Biber) j 
— I good_day_name : ( 

good_day_name (the_day_naae) 

( (Monday <=the_day_name) OR (the_day_name<=Sunday) ) ) ; 
day_val_0 : (day_name_sort_tic_val(0)=Monday) ; 
day_val_l : (day_name_sort_tic_val(l)=Tuesday) ; 
day_val_2: (day_name_sort_tic_val(2)=Vedne8day) ; 
day_val w 3 : (day_name_Bort_t ic_val(3) =Thursday ) ; 
day_val_4 : (day_najae_sort.ticrval(4)=Friday) | 
day_val_5 : (day_name_8dft_tic_vai(5)=Saturday) ; 
day_val_6: (day_name_sort_t ic_val (6) ^Sunday) ; 
f irst.millisecond: (miiliseconds_tic_first=0) ; 
f irat^second: (seconds_tic_f irst=0) ; 
f irst_minute: (minutes.tic.f irst=0) f 
first.hou r: (hours_tic_first=0) ; 
first_year: (years_tic_first=1901) ; 
f irst_month: (month_name_sort_tic_f irst= January) ; 
last^month : (month_name_sort_tic_last = D6C6niber) ; 
duration_sort_identity : ( 
duration_sort_identity (the_duration) 

the.duration) ; 

— I day_name_ sort ..increment: ( 

day_name_sort_increment (the_day_name , offset) 

day_name_sort_tic_val ( 

( (day_name_sort_tic_pos (the_day_name) +of f set ) MOD 7))); 

— I good w duration: ( 

good_durat ion ( the_durat ion) 

good_f ixnum(the_duration)) ; 

— I good.day: (good_day(the_day)=(0<=the_day)) ; 

— I good_hour : ( 

good_hour(the_hour) 


( (0<=the_hour) AND (the_hour<24))) ; 

— I good_minute; ( 

good_minute(the_minute) 

( (0<=the_minute) AID (the_minute<60))) ; 

— I good_second: ( 

good_8econd(the_second) 
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((0<=the.second) AID (the_second<60))) ; 

— I good.millisecond: ( 

good.millisecond(the.millisecond) 

((0<=the.millisecond) AID (the_millisecond<1000)) ) ; 

— I good. interval: ( 

good.interval (the.interval) 

( 

( 

( 

( 

good.day (the.interval . elapsed.days) 

AID 

good.hour (the.interval . elapsed.hours) ) 

AID 

good.minute (the. interval . elapsed.oinutes) ) 

AID 

good.second( the. interval. elapsed.seconds)) 

AID 

good_millisecond(the_interval. elapsed.milliseconds))) ; 

— I EID AXIOMS; 

— I LEMMAS: FORALL [the.day.name : day .name. sort , the.pos:Int ( 
the. second : seconds] 

— I day .name. sort. tic.pos : ( 

( 

( 

( 

( 

( 

(day .name.sort .tic.pos (Monday) =0) 

AID 

(day_name_sort_tic_pos(Tuesday)=l)) 

AID 

(day.name_sort.tic.pos (Wednesday) =2) ) 

AID 

(day .name.sort .tic.pos (Thursday) =3)) 

AID 

(day.name_sort.tic.pos (Friday) =4)) 

AID 

(day .name.sort. tic.pos (Saturday) =5) ) 

AID 

(day.name_sort_tic.pos (Sunday) =6) ) ; 

— I day .name. sort .tic.pos. range: ( 
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(0<=day_na®e_sort_t ic_pos (the_day_name) ) 

AID 

(day_name_sort_tic_pos(the_day_name)<=6)} ; 

— I day_name_sort_tic_val_range : ( 

((0<=the_pos) AID (the_pos<=6)) 

-> 

( 

(Monday<=day_name_sort_tic_val (the_pos) ) 

AID 

(day_name_sort_tic_val(the_pos) <=Sunday) ) ) ; 

— I seconds_to_duration: ( 

seconds_to_duration(the_second) 

pair(the_ second, 1)); 

— I END LEMMAS; 

— I TRAIT conversion_iactors IS 

— I DECLARES 

— | INTRODUCES 

— I days_to_hours: -> hours; 

— I hour8_to_minutes : -> minutes; 

— I hours_to_seconds : -> seconds; 

— I days_to_seconds : -> seconds; 

— I minutes^to^seconds : -> seconds; 

— I days_to_milliseconds : -> milliseconds; 

— I seconds_to_milliseconds : -> milliseconds; 

— I seconds_to_catu: -> catu; 

— I milliseconds_to_catu: -> catu; 

— i AXIOMS: 

— I hours_to_minutes : (hours_to_minutes=60) ; 

— I days_to_hours : (days_to_hours=24) ; 

— I minutes_to_seconds : (minutes_to_seconds=60) ; 

— I seconds_to_milliseconds : (secondB_to_millisecond8=1000) ; 

— I days_to_seconds : ( 

days_to_seconds 

SE 

((days_to_hours*hours_to_minutes)*minutes_to_seconds)) ; 

— I hours_to_seconds: ( 

hours_to_seconds 

(hours_to_minutes*minutes_to_seconds)) ; 

— I milliseconds_to..catu: (milliseconds_to_catu>0) ; 

— I seconds_to_catu: ( 

seconds_to_catu 
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(8econds_to_milliseconds*milliseconds_to_catu) ) ; 

END AXIOMS; 

LEMMAS: 

END LEMMAS; 

TRAIT time_representations IS 
DECLARES 
INTRODUCES 

days_in_month: months, years -> month_days; 
is_leap_year : years -> Bool; 
is_non_leap_ centennial : years -> Bool; 
days_in_year : years -> year_days; 
days_of_years_since_1900: years -> absolute.days; 
seconds_since_1900: time_sort -> seconds; 
days_since_Jan: months, years -> year_days; 
day_name_of : years, year^days -> day _name_ sort ; 
day_of_year: years, months, month_days -> year_days; 
month_of: years, year_days -> months; 
day_o:f_month: years, year_days -> month_days; 
year_of : absolute_days -> years; 
good_year: years -> Bool; 
good_month : months -> Bool; 
good_month_day : month_days -> Bool; 

good_date: years, months, month_days, duration.sort - 
good.time: time_sort -> Bool; 
good_year_and_day : years, year_days -> Bool; 
day_name_sort_val : Int -> day_name_sort ; 
time.oi: years, 
months , 
month_days , 

duration_sort -> cal endar _ timers or t ; 

— | AXIOMS: FORALL [the_month : Int , the_year: Int , 
the, time: time, sort , the_year_day : Int , the_month_day : Int , 
the_absolute_day : Int] 

— I days_in_January : (days_in_month(l , the_year)=31) ; 

— I days_in_February : ( 

days_in_month(2, the_year) 

(IF is_leap_year(the_year) THEN 29 ELSE 28)); 
days_in_March: (days_in.j&onth(3, the_year)=31) ; 
days_in_April: (days_in_month(4, the - .yeair)=30) ; 
days_in_May: (days_in_month(5, the_year)=31) ; 
days_in_June: (days_in_month(6, the_year)=30) ; 
days_in_July : (days_in_month(7, the_year) s =31) ; 
days_in_August : (days_in_month(8, the_year)=31) ; 


> Bool; 
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— I days_in_September: (days_in_month(9, the_year)=30) ; 
“I days_in_October: (days_in_month(10, the_year)=31) ; 

— I days_in_Iovember: (days_in_aonth(ll , the_year)=30) ; 

— I days_in_December : (days_in_aonth(12, the_year)=31) ; 

— I leap-year: ( 

is_leap_year(the_year) 

C 

C(the_year MOD 4)=0) 

AID 

(I0T is_non_leap_centennial(the_year)))) ; 

— I non_leap_ centennial: ( 

is_non_leap_centennial (the.year ) 

(((the_year MOD 100)=0) AID ((the_year MOD 400)/=0))); 

— I days _in_y ear : ( 

days_in_year(the_year) 

(IF is_leap__year(the_year) THEI 366 ELSE 366)); 

— I days_since_i900_0: (days_of_years_since_1900(1900)=0) ; 

— I days_since_1900_l: ( 

(the_year>1900) 

-> 

( 

days_of_years_since_1900(the_yeax) 

( 

days_in_year ( (the_year-l) ) 

+ 

days_o*_years_since_1900( (tha.year-l) ) ) ) ) ; 

— I days _since_ January _0 : (days_since_Jan(l , tke_year)=0) ; 

— I days_since_January_l : ( 

(the_oonth>l) 

-> 

( 

day8_since_Jan(the_month, the_year) 

( 

days_in_montli((the_Bonth-l) , the_yaar) 

+ 

days_since_Jan((the_aonth-l) , the_year)))) ; 

— I good_year: ( 

good_year (the_year ) 
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((1901<=the_year) AID (the_year<=2099))) ; 

— I good_month : ( 

good_month ( the.month) 

s 

((l<=the_month) AID (the.month<=12))) ; 

— I good.month.day: ( 

good.month.day(the.month.day) 

s 

( ( l<=the.month_day ) AID (the.month.day<=31))) ; 

— I good. time: ( 

good.t ime ( the.t ime ) 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 

( 1901<=the_t ime . the.year) 
AID 

(the.t ime . the.y ear<=2099) ) 

AID 

( l<=the_time . the.month) ) 

AID 

(the.t ime . the.month<=12) ) 

AID 

( K=the_t ime . the.day) ) 

AID 

( 

the.t ime . the.day 

<= 

days. in.month (the.t ime . the.month , 
the.t ime . the.year) ) ) 

AID 

(0<=the_t ime ♦ the.hour) ) 

AID 

(the.t ime . the.hour<days.to_houxs) ) 
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AND 

(0<=the_time . the.ainute)) 

AND 

(the_tim6 . the_minute<houra_to_»iiiutes) ) 

AND 

(0<=the..tiae . the_second) ) 

AND 

(the_t ime . the_second<ainutes_to_s©conds) ) 

AND 

(0<=the_t ime . the_millisecond) ) 

AND 

(the_time . the_millisecond<seconds_to_milliseconds) ) ) ; 

— I good_year_and_day : ( 

goodly ear_and_day(the_y ear, the_year_day) 

( 

((1901<=the_year) AND (the_year<=2099)) 

AND 

( 

( K=the_year_day) 

AND 

(the_y ear_day<=days_in_year (the_year) ) ) ) ) ; 

— I day_name : ( 

day_name_of (the_year, the_year_day) 

day_name_sort_tic_val ( 

( 

(day B_of _y ears^s ince. 1 900 (the.year) + (the_year_day- 1 ) ) 
MOD 
7))); 

— I day_of_year: ( 

day_ol_year(the_year , the_aonth, the_aontli_day) 

(days_since_Jan(the_month, the_year)+the_moiith_day) ) ; 

— I month_oJ : ( 

( 

(days_since_Jan(the_aonth, tlie_year)<the_year_day) 

AND 

( 

the_year_day 

<= 

( 

day s_s ince_ Jan (the_aonth f the_year ) 

+ 
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days. in_month( the.month , the.year) ) ) ) 

-> 

(month.of (the.year, the.year.day )=the_month)) ; 
— I day .of .month. : ( 

day. of .month ( the.year , the.year.day ) 


( 

the.year.day 

days. since. Jan(month.of (the.year t the.year.day) , 
the.year))) ; 

— I ye ax. of : ( 

( 

(days_of_years_since_1900(the.year)<the_absolute.day) 

AID 

(the.absolute.day<=days_of .years. since.l900( (the.year+1) ) ) ) 

-> 

(year. of (the.absolute.day ) = the.year ) ) ; 

— I seconds.since.1900: ( 

seconds. since. 1900 (the.time) 

( 

( 

( 

( 

( 

day s.of. years. since. 1900(the.time . the.year) 

* 

days.to.seconds) 

+ 

Int.identity( 

( 

days.8ince_Jan( the.time . the.month , 
the.time . the.year) 

* 

days.to.seconds) ) ) 

+ 

Int. identity ( (the.time . the_hour*hours.to_seconds) ) ) 

+ 

Int.identity ( (the.time . the.minute*minutes.to.seconds) ) ) 

+ 

duration sort identity (the.time* the. second) ) ) ; 

— | EID AXIOMS; 

— I LEMMAS: FORALL [the.year : years , the.month : months] 
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— I day ..name _of : (day.name.ol (1900, l)=Tnesday) ; 

— I day8_in_months: ( 

days_in_month(the_month, the.year) 


( 

IF (the_month=l) 

THE! 31 
ELSE ( 

IF (the_month=2) 

THEI (IF ia_leap_year(the_year) THEM 29 ELSE 28) 
ELSE ( 

IF (the_month=3) 

THEI 31 
ELSE ( 

IF (tlie_month=4) 

THEM 30 
ELSE ( 

IF (the_month=5) 

THEI 31 
ELSE ( 

IF (the_month=6) 

THEI 30 
ELSE ( 

IF (the_month=7) 

THEI 31 
ELSE ( 

IF (the_month=8) 

THEI 31 
ELSE ( 

IF (the_month=9) 

THEM 30 
ELSE ( 

IF (the_month=10) 
THE! 31 
ELSE ( 

IF (the_montIi=ll) 
THEM 30 
ELSE 


— I number_o* .months : ( 
good_month(the_month) 

-> 


31 )))))))))))); 
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( 

( 

( 

( 

( 

( 

( 

( 

((the_month=l) OR (the_month=2)) 
OR 

(the_month=3)) 

OR 

(the_month=4)) 

OR 

(the.month=E)) 

OR 

(the_month=6)) 

OR 

(the.month=7) ) 

OR 

(the_month=8) ) 

OR 

(the_month=9) ) 

OR 

(the_month=10) ) 

OR 

(the_month=ll)) 


OR 

(the_month=12) ) ) ; 

— I days.in.month.range: ( 
good.month ( t he.mont h ) 

-> 


( 

( l<=days_in.month(the.month , the.year) ) 

AID 

(days.in.month(the_month, the.year) <=31))) ; 

— I day s_since_ January .positive : ( 

good.month ( the.month ) 

-> 

(0<=days_since.Jan(the.month, the.year))) ; 

— I days.since.January.upper.bound: ( 

(good.month (the.month) AID good.year(the.year) ) 

-> 

(days. since. Jan(the.month, the.year) <-335)) ; 
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— I days_in,year_identity : ( 

days, in,year(the,y ear) 

( 

days, since, Jan(months,tic_last , the_year) 

+ 

day s_in,month (months, tic_last , the_year) ) ) ; 

— I END LEMMAS; 

I TRAIT time,representation_conversions IS 
“I DECLARES 
“I INTRODUCES 

I time,to_cal,time : time, sort -> calendar,time,sort ; 

I cal,time_to,time: cal endar_time_ sort -> time, sort ; 

I round,cal,time_dora,to_milliseconds : 

calendar,time,sort -> calendar, time, sort ; 

I interval,to,duration: interval_sort -> duration,sort ; 

— I round_duration_doffn_to,jttillisecondsr 

duration,sort -> time,sort; 

I duration,to,interval: duration, sort -> interval_sort ; 

I AXIOMS: fORALL Cthe_time : time, sort , 
the,calendar_time : cal endatr, time, sort , 
the,interval : interval_sort , the,duration:duration,sort , 
tlie, second : seconds] 

— j time_to_cal_time : ( 

time_to,cal_time(the,time) 

( 

(seconds, since, 1900(the_time.the,year)*seconds,to,catu) 
+ ” - 

( X - - ■ • -x- ; 

calendar_t ime,sort_ identity (the_timethe,mill is econd) 

+ 

milliseconds,to,catu) ) ) ; 

— I round,cal,time_down: ( ^ ^ 

round,cal,time_down,to_milliseconds(the_calendar,time) 

( 

the, calendar .time 

(the,calendar,tijne MOD milliseconds_to,catu)) ) ; 

— I t ime_to_cal,time : ( 

( 


time_to_cal,time(the_time) 
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round_cal_time_down_to.milliseconds(the.calendar_time) ) 

-> 

( cal.t ime.to.t iae ( the.calendar.t ime ) =the_t ioe ) ) ; 

— I interval.to.duration: ( 

int erval.to.duration( the. int erval) 

( 

( 

( 

( 

s econds_t o.durat ion ( 

(the.interval . elapsed.days*day8_to_seconds) ) 

+ 

Beconds_to_duration( 

(the. interval . elapsed_hours*hours.to. seconds) ) ) 

+ 

s econds.t o.durat ion ( 

(the.interval . elapsed_minutes*minutes.to.seconds) ) ) 

+ 

seconds.to.duration(the_interval . elapsed.seconds)) 

+ 

( 

seconds_to.duration(the.interval . elapsed_milliseconds) 

/ 

seconds.to.milliseconds) ) ) ; 

— I good.interval.to.good.duration: ( 

( 

good. int erval ( the. int erval ) 

AID 

( the.dur at ion= int erval.to.durat ion ( the. interval) ) ) 

-> 

good.duration(the.duration)) ; 

— | round.duration.down: ( 

T-rmnd duration down to milliseconds (the. duration) 

( 

s econds.t o.durat ion ( 

Floor((the_duration*second8.to_niilliseconds))) 

/ 

seconds.to.milliseconds)) ; 

— I good.seconds.to.good.duration: ( 

good.second (the. second) 

-> 

good.durat ion(seconds.to.duration(the.Becond) ) ) ; 
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— | END AXIOMS; 

— I LEMMAS: FORALL [dl : duration. sort , d2 : duration. 8 or t , 
m:duration_sort , n:duration.sort , p:duration_sort] 

— I good.duration.pair: (FORALL n:Int, 

d : Int : ; ( (d/=0 ) ->good_dur at ion (pair (n , d) ) ) ) ; 

— I good.duration.8Xim: ( 

(good.duration(dl) AND good.duration(d2)) 

-> 

good_duration((di+d2))) ; 

— I subtract.duration.equals: (FORALL ®:duration.sort , 
n:duration_sort , prduration.sort : : ((m=(n-p))->((m+p)=n)) ) ; 

— I END LEMMAS; 

PACKAGE built in IS 

TYPE duration IS RECORD 
sign: integer; 
whole.part: integer; 
fraction: integer; 

END RECORD; 

TYPE string IS ARRAY (integer) OF character; 

FUNCTION durat ion. ize( seconds : IN integer) RETURN duration; 
— | WHERE 

— I RETURN seconds. to.durat ion (seconds) ; 

— I RETURN result SUCH THAT good.durat ion (result) ; 

— I END WHERE; 

END built in; 

WITH built in; 

PACKAGE calendar IS 

TYPE time IS NEW integer; 

TYPE year .number IS NEW integer; 

TYPE month.number IS NEW integer; 

TYPE day .number IS NEW integer; 

TYPE day. duration IS NEW built in. duration; 

FUNCTION clock RETURN time; 

--I WHERE 

— I END WHERE; 

FUNCTION year (date : IN time) RETURN year.number; 

— I WHERE 

— I RETURN extract.year(date) ; 

— I END WHERE; 

FUNCTION month(date : IN time) RETURN month.number; 
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— I WHERE 

— | RETURI extract .month (date) ; 

— I EID WHERE; 

FUICTIOI day (date : II time) RETURI day_number; 

— I WHERE 

— | RETURI extract_day(date) ; 

— | EID WHERE; 

FUICTIOI seconds (date : II time) RETURI day_duration; 

— | WHERE 

— | RETURI extract_duration(date) ; 

| RETURI result SUCH THAT good_duration(result) ; 

— I EID WHERE; 

PROCEDURE split (date : II time; 
year : OUT year. number; 
month : OUT month.number ; 
day : OUT day .number; 
seconds : OUT day .duration) ; 

— | WHERE 

—| OUT (year=extract_year(date)) ; 

— | OUT (month=extract_month(date)) ; 

— | OUT (day=extract_day(date)) ; 

— | OUT (seconds=extract_duration(date)) ; 

— | EID WHERE; 

FUICTIOI time_of(year : II year_number; 
month : II month_number ; 
day : II day_number; 

seconds : II day.duration) RETURI time; 

— I WHERE 

— | II good_date(year, month, day, seconds); 

— | RETURI time_of (year, month, day, seconds); 

— I EID WHERE; 

FUICTIOI "+"(left : II time; 

right : II builtin. duration) RETURI time; 

— | WHERE 

—| RETURI (left+right); 

— I EID WHERE; 

FUICTIOI "-"(left : II time; 

right : II builtin. duration) RETURI time; 
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— I WHERE 

— I RETURI (left-right); 

— I EID WHERE; 

FUHCTIOI "<"(left, right : II time) RETURI boolean; 

--I WHERE 

— I RETURI (leftcright) ; 

— I EID WHERE; 

FUICTIOI "<="(left, right : II time) RETURI boolean; 

— I WHERE 

— I RETURI (lef t<=right) ; 

--I EID WHERE; 

FUICTIOI ">" (left, right : II time) RETURI boolean; 

--I WHERE 

— I RETURI (left>right) ; 

— I EID WHERE; 

FUICTIOI ">="(lef t , right : II time) RETURI boolean; 

--I WHERE 

— I RETURI (left>=right) ; 

— I EID WHERE; 

FUICTIOI day_duration_ize(seconds : II integer) 

RETURI day_duration; 

--1 WHERE 

I RETURI seconds_to_duration(seconds) ; 

I RETURI result SUCH THAT good_durat ion (result ) ; 

--I EID WHERE; 

EID calendar ; 

WITH built in; 

PACKAGE integer.utilities IS 
TYPE number IS IEW integer; 

TYPE base IS IEW integer; 

TYPE numbers IS ARRAY (integer) OF number; 

FUICTIOI min(left ; II number; 

right : II number) RETURI number; 

--I WHERE 

— I RETURI (IF (left<right) THEI left ELSE right); 

--I EID WHERE; 


uni mi i lias ■ mi hi ii ii hi mill inm n mi 
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FUICTIOI min(the_numbers : II numbers) RETURI number; 

— I WHERE 

— I EMD WHERE; 

FUICTIOI max(left : II number; 

right : II number) RETURI number; 

— I WHERE 

--I RETURI (IF (left>right) THEI left ELSE right); 

--I EID WHERE; 

FUICTIOI max(the_numbers : II numbers) RETURI number; 

--I WHERE 

— I EID WHERE; 

FUICTIOI is_positive(the_number : II number) RETURI boolean; 
--I WHERE 

— I RETURI (the_number>0) ; 

— I EID WHERE; 

FUICTIOI is_natural(the_number : II number) RETURI boolean; 

— I WHERE 

— I RETURI (the_number>=0) ; 

--I EID WHERE; 

FUICTIOI is_negative(the_number : II number) RETURI boolean; 

— I WHERE 

— I RETURI (the_number<0) ; 

— I EID WHERE; 

FUICTIOI is_zero(the_number : II number) RETURI boolean; 

— I WHERE 

— I RETURI (the_number=0) ; 

— I EID WHERE; 

FUICTIOI is_odd(the_number : II number) RETURI boolean; 

— I WHERE 

--I RETURI ((the.number MOD 2)=1); 

— I EID WHERE; 

FUICTIOI is_even(the_number : II number) RETURI boolean; 

— I WHERE 

—I RETURI ((the.number HOD 2)=0); 

— I EID WHERE; 
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FUNCTION image_of (the_number : IM number; 

with_the_base : IN base) RETURN built in, string; 

--I WHERE 
--I END WHERE; 

FUNCTION value_of (the_image : IN built in. string; 
with.the^base : IN base) RETURN number; 

— I WHERE 

— I END WHERE; 

END integer_utilities ; 

WITH built in; 

PACKAGE duration_utilities IS 

TYPE number IS NEW built in. duration; 

FUNCTION integer_part (the_number : IN number) RETURN integer; 

— I WHERE 

— I IN good_duration(the_number) ; 

— I RETURN IntegerPart (the.number) ; 

— | END WHERE; 

FUNCTION real_part (the_number : IN number) RETURN number; 

--I WHERE 

— I IN good_duration(the_number) ; 

— i RETURN RealPart (the_nuraber) ; 

— I RETURN result SUCH THAT good_durat ion (result ) ; 

— I END WHERE; 

FUNCTION floor (the_number : IN number) RETURN integer; 

— I WHERE 

— I IN good_duration(the_number) ; 

— I RETURN Floor (the_number) ; 

— I END WHERE; 

FUNCTION ceiling (the_number : IN number) RETURN integer; 

— I WHERE 

— I IN good_duration(the_number) ; 

— I RETURN Ceiling(the_number) ; 

— I END WHERE; 

END duration.utilities; 

WITH built in, calendar; 

PACKAGE calendar.utilities IS 
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TYPE natural IS HEW integer; 

TYPE string IS ARRAY( integer) OF character; 

TYPE year IS HEW calendar .year .number; 

TYPE month IS HEW integer; 

TYPE day IS HEW integer; 

TYPE hour IS HEW integer; 

TYPE minute IS HEW integer; 

TYPE second IS HEW integer; 

TYPE millisecond IS HEW integer; 

TYPE time IS RECORD 
the.year : year; 
the.month: month; 
the.day : day; 
the.hour: hour; 
the_minute: minute; 
the.second: second; 
the.millisecond: millisecond; 

EHD RECORD; 

TYPE interval IS RECORD 
elapsed.days: natural; 
elapsed.hours : hour; 
elapsed.minutes: minute; 
elapsed.seconds : second; 
elapsed.milliseconds : millisecond ; 

EHD RECORD; 

TYPE year.day IS HEW integer; 

TYPE month.name IS (january, lebruary, march, april, may, 

june, july, august, September, October, november, december); 

TYPE day .name IS (monday, tuesday, Wednesday , thursday, 

iriday, Saturday, Sunday); 

TYPE period IS (am, pm); 

TYPE time.lormat IS (lull, military); 

TYPE date.lormat IS (lull, month.day.year) ; 

FUHCTIOH natural_ize(m : IH integer) RETURH natural; 

— I WHERE 

— | IH (0<=m) ; 

— | RETURH m; 

— I EHD WHERE; 

FUHCTIOH integer_ize(m : IH integer) RETURH integer; 

— I WHERE 

— | RETURH m; 

— I EHD WHERE; 
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FUICTIOI year_day_ize(m : II integer) RETURI year.day; 
--I WHERE 

--I II (Cl<=m) AID (m<=366)) ; 

— I RETURI m; 

— I EHD WHERE; 

FUICTIOI day_ize(m : II integer) RETURI day; 

— I WHERE 

--I II ((l<=m) AID (m<=31) ) ; 

— I RETURI m; 

— I EID WHERE; 

FUICTIOI hour_ize(m : II integer) RETURI hour; 

--I WHERE 

--I II ( (0<=m) AID (m<24)) ; 

— I RETURI m; 

— I EID WHERE; 

FUICTIOI minute, ize(m : II integer) RETURI minute; 

— I WHERE 

--I II ( (0<=m) AID (m<60)) ; 

— I RETURI m; 

— I EHD WHERE; 

FUICTIOI 8econd_ize(m : II integer) RETURI second; 

— I WHERE 

— I II ((0<=m) AID (m<60)) ; 

— I RETURI m; 

— I EID WHERE; 


FUICTIOI millisecond_ize(m : II integer) RETURI millisecond; 
--I WHERE 

--I II ( (0<=m) AID (m<1000)) ; 

— I RETURI m; 

--I EID WHERE; 


FUICTIOI millisecond. ize(m : II built in. duration) 
RETURI millisecond; 

--I WHERE 

— I RETURI Floor ((lOOO*m)); 

--I EID WHERE; 

FUICTIOI year_number_ize(the_year : II year) 
RETURI calendar. year .number; 
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— I WHERE 

— I II good_year(the_year) ; 

— I RETURI the.year; 

— I EID WHERE; 

FUICTIOI month_number_ize(the_month : II month) 

RETURI calendar .month_number ; 

— I WHERE 

— I II good_month(the_month) ; 

— | RETURI the_month; 

— I EID WHERE; 

FUICTIOI day_number_ize(the_day : II day) 

RETURI calendar. day_nnmber; 

— I WHERE 

— | II good_»oath_day(the_day) ; 

— | RETURI the.day ; 

— I EID WHERE; 

FUICTIOI year_tic_f irst RETURI integer; 

— I WHERE 

— I RETURI years_tic_lirst ; 

--I EID WHERE; 

FUICTIOI month_name_tic_pos(the_month : II month_name) 
RETURI month; 

— I WHERE 

— I RETURI month_name_sort_tic_pos(the_month) ; 

— 1 EID WHERE; 

FUICTIOI month_name_tic_val( index : II integer) 

RETURI month.name; 

— I WHERE 

— I II good_month((index+i)) ; 

— I RETURI month..name_sort_t ic_val( index) ; 

“I EID WHERE; 

FUICTIOI day_name_tic_pos(the_day : II day_name) 

RETURI integer; 

--I WHERE 

— 1 RETURI day_name_sort_tic_pos(the_day) ; 

— I EID WHERE; 


FUICTIOI day_name_tic_val( index : II integer) RETURI day_name; 
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— I WHERE 

— I RE TURK day_name_Bort_tic_val(index) ; 

— I RAISE constraint.error <=> II ( 

(indexCO) 

OR 

(index>6)) ; 

— I END WHERE; 

FUNCTION millisecond_tic_first RETURf millisecond; 

— I WHERE 

— I RETURI milliseconds_tic_first; 

— I END WHERE; 

FUNCTION second_tic_first RETURN second; 

— I WHERE 

— | RETURN seconds_tic_lirst; 

— I END WHERE; 

FUNCTION minute.tic .first RETURN minute ; 

--I WHERE 

— I RETURN minutes_tic_f irst; 

--I END WHERE; 

FUNCTION hour_tic_f irst RETURN Hour; 

— I WHERE 

— I RETURN hour s_tic_f irst; 

— I END WHERE; 

FUNCTION month_tic_f irst RETURN month; 

— I WHERE 

— I RETURN month8_tic_first; 

— I END WHERE; 

FUNCTION month.tic.last RETURN month; 

--I WHERE 

— I RETURN months_tic_last; 

--I END WHERE; 

FUNCTION is_leap_year(the_year : IN year) RETURI boolaan; 

— I WHERE 

— I RETURN is_laap_year(the_yaar); 

--I END WHERE; 

FUNCTION days_in(the_year : IN year) RETURI year.day; 



APPENDIX E 


97 


— I WHERE 

— I II good_year(the_year) ; 

— | RETURH days_in_year(the_year) ; 

— I EHD WHERE; 

FUICTIOH days_in(tbe_montb : II month; 

the_year ; II year) RETURI day; 

--I WHERE 

— I II good_month(the_month) ; 

— | II good_year(the_year) ; 

— | RETURI days_in_month(the_month, the_year); 

— I EID WHERE; 

FUICTIOI month_ol (the_month : II month) RETURI month.name; 

— I WHERE 

— | II good_month(the_month) ; 

— I RETURH month_name_sort_tic_val((the_month-l)) ; 

— I EHD WHERE; 

FUICTIOI month.of (the_month : II month_name) RETURI month; 

— I WHERE 

— I RETURH (month_name_sort_tic_pos(the_month)+l) ; 

--I EID WHERE; 

FUICTIOI day_of (the_year : II year; 

the_day : II year_day) RETURI day_name; 

— I WHERE 

— | II good_year_and_day(the_year, the_day); 

— | RETURI day_name_of (the_year , the_day) ; 

--I EHD WHERE; 

FUICTIOI day.of (the_time : II time) RETURI year_day; 

— I WHERE 

— I II good_time(the_time) ; 

— I RETURI day_of_year(the_time.the_year, 

the_t ime . the.month , the_t ime . the_day ) ; 

--I EID WHERE; 

FUICTIOI time_oT (the_year : II year; 

the_day : II year_day) RETURI time; 

--I WHERE 
-I 

— I 

( 


II good_year_and_day(the_year, the_day) ; 
RETURI t SUCH THAT ( 
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( 

( 

( 

( 

(t . the_year=the_year) 

AND 

(t . the_moEth=month_ol (the_year , the_day ) ) ) 

AMD 

(t . the_day=day_of _month(the_year, the_day) ) ) 

AMD 

(t . the_hour=0)) 

AMD 

(t . the_minute=0) ) 

AMD 

(t . the_second=0) ) 

AMD 

(t . the_millisecond=0) ) ; 

— I EMD WHERE; 

FUMCTIOM period_ol (the_time : IM time) RETURI period; 

~ I WHERE 

— | IM good_time(the_time) ; 

— I RETURM (IF (the_time.the_hour<12) THEM am ELSE pm); 

— | EMD WHERE; 

FUMCTIOM time_oI (the_time : IM time) RETURI calendar . time; 

— | WHERE 

— | IM good_time(the_time) ; 

— I RETURM time_to_cal_time(the_time) ; 

— I EMD WHERE; 

FUMCTIOM time_ol(the_time : IM calendar. time) RETURI time; 

— I WHERE 

— I RETURM cal_time_to_time(the_time) ; 

— I EMD WHERE; 

FUMCTIOM duration_of(the_interval : II interval) 

RETURI built in. duration; 

— I WHERE 


— I RETURM interval_to_duration(tlie_interval) ; 

— | RETURM result SUCH THAT good_duration(result) ; 


— | EMD WHERE; 


FUICTIOI intervals! (the_durat ion : II built in. duration) RETURI 
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interval; 

— I WHERE 

— | RETURI duration.to.interval(the.duration) ; 

— I EID WHERE; 

END calendar.utilities; 


WITH integer.utilities, duration.utilities, built in; 

PACKAGE BODY calendar.utilities IS 

TYPE month.day IS ARRAY (month) OF day; 
century.off set : Integer := 1900; 
days.per.year : year .day := 365; 
first. day ; day.name := tuesday; 
seconds. per .minute : Integer := 60; 

seconds.per.hour : Integer := (60*seconds_per_minute) ; 

seconds.per.day : Integer := (24*seconds.per_hour) ; 

milliseconds.per.second : Integer := 1000; 

noon : Integer := 12; 

time.separator : Character := 1 

date. separator : Character := */ % \ 

blank : Character := 9 1 ; 

comma : Character := * 

zero : Character := *0'; 

FUICTIOI H +"(n, n : II built in. duration) 

RETURI built in. duration; 

WHERE 

II good.duration(m) ; 

II good.duration(n) ; 

RETURI (m+n) ; 

RETURI result SUCH THAT good.durat ion (result ) ; 
EID WHERE; 


FUICTIOI "-"(m, n : II built in. duration) 

RETURI built in. duration; 

WHERE 

II good.duration(m) ; 

II good.duration(n) ; 

RETURI (m-n) ; 

RETURI result SUCH THAT good.durat ion (result ) ; 
EID WHERE; 


FUICTIOI "*"(*, n : II built in. duration) 
RETURI built in. duration; 

— I WHERE 
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— I IM good_duration(n) ; 

— I II good_duration(n) ; 

— | RETURI (m*n) ; 

— I RETURI result SUCH THAT good_duration(result) ; 

--I END WHERE; 

FUICTIOI "/"(m, n : II built in. duration) 

RETURI built in. duration; 

— I WHERE 

— I II good_duration(m) ; 

— I II good_duration(n) ; 

— I II (n/=Int_to_f ixnum(O)) ; 

--I RETURI (m/n); 

— I RETURI result SUCH THAT good_duration(result) ; 

--I EID WHERE; 

FUICTIOI "*"(ia : II built in. duration; 

n : II integer) RETURI built in. duration; 

--I WHERE 

— I II good_duration(m) ; 

-- I RETURI (m*n) ; 

— I RETURI result SUCH THAT good^durat ion (result) ; 

— I EID WHERE; 

FUICTIOI "/"(» : II builtin. duration; 

n ; II integer) RETURI builtin. duration; 

--I WHERE 

— I II good_duration(m) ; 

— I II (n/=0) ; 

— I RETURI (m*n) ; 

— I RETURI result SUCH THAT good_duration(result) ; 

--I EID WHERE; 

FUICTIOI days_per_month(the_month : II month) RETURI integer; 

— I WHERE 

— I II ((K=the_month) AID (the_nonth<=12)) ; 

— | RETURI ( 

( 

( 

( 

( 

( 

( 

( ( ( ( ( (month_days_tic [l=>31] ) [2=>28] ) [3=>31] ) 
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[4=>30] ) [5=>31] ) [6=>30] ) [7=>31] ) [8=>3l] ) 
[9=>30] ) [10=>31] ) [11=>30] ) [12=>31] ) 
[the.month] ) ; 

— I EID WHERE; 

FUICTIOI is.leap.year(the.year : II year) RETURI Boolean 

— I WHERE * * * 

— i RETURI is.leap.year (the.year) ; 

— I EID WHERE; 

— ! VC Status: proved 

— ! BY instantiation of axiom leap.year 
in trait time.representations 
— ! WITH the.year FOR the.year : Int 

— ! BY instantiation of axiom non.leap.centennial 
in trait time.representations 
— ! WITH the.year FOR the.year: Int 

— ! BY instantiation of lemma mod.tr ans it ive in trait Z 
— ! WITH 100, 4, the.year FOR ml: Int, m2: Int, a: Int 

— ! BY left substitution of 1 
— ! BY left substitution of 2 
— ! BY simplification 
— ! BY synthesis of TRUE 
— ! □ 

IS 


BEGII 

IF ((the.year HOD 100) =0) THEI 
RETURI ( (the.year HOD 400) =0); 

ELSE 

RETURI ( (the.year HOD 4)=0); 

EID IF; 

EID is.leap.year; 

FUICTIOI days_in(the_ye^ : II year) RETURI year.day 
— | WHERE 

— I GLOBAL days.per.year : II ; 

— I II (days_per_year=365) ; 

— 1 RETURI days.in.year(the.year) ; 

— I EID WHERE; 

— ! VC Status: proved 

— ! BY axiom days.in.year in trait time.representations 
— ! WITH the.year FOR the.year:Int 

— t substituting for left 
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— ! BY simplification 
— ! BY synthesis of TRUE 

— f □ 

IS 


BEGII 

IF is_leap_year(the_year) THEI 
RETURI (days_per_year+l) ; 

ELSE 

RETURI days_per_year ; 

EID IF; 

EID days_in; 

FUICTIOI days_in(the_month : II month; 
the^year : II year) RETURI day 

— I WHERE * * * 

— I II good_month(the_month) ; 

— I II goodly ear (the.year) ; 

— I RETURI days_in_month(the_month, the.year) ; 

— I EID WHERE; 

— ! VC Status : proved 

— ! BY axiom month_pos_f ebruary in trait sort _names 
— ! WITH FOR 

— ! substituting for left 

“! BY instantiation of lemma number_of_months 
in trait time.representations 
— ! WITH the_month FOR thejnonth: Int 

— ! BY analysis of IMPLIES, in 3 
— ! BY hypothesis 

— ! AID THEI 

— ! BY contradiction, in 1 

— ! BY axiom good_month in trait time.representations 
— ! WITH the_month FOR the.month : Int 

— ! substituting for left 

— ! BY contradiction, in i 

— ! BY lemma days_in_months in trait time^repre sent at ions 

— i WITH the_month, the.year FOR the_month : Int , 

the_year : Int 

— ! substituting for left 

— ! BY cases, using (the_month=l) 

— ! CASE TRUE 

— ! BY left substitution of 4 

— ! BY synthesis of TRUE 
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— ! 
— ! 
— ! 
— ! 
— ! 

— ! 
— ! 
— ! 
— ! 
— ! 


— ! 


— ! 
— ! 


— ! 
-- ! 


— I 
— ! 
— ! 
— ! 
— ! 
— ! 
— ! 

— i 


— ! 
— ! 
— ! 

— ! 
— ! 
— ! 


CASE FALSE 

BY cases, using (the_month=2) 

CASE TRUE 

BY left substitution of 5 
BY axiom days_in_February 

in trait time.representations 
WITH the.year FOR the_year : Int 
substituting for left 
BY simplification 
BY synthesis of TRUE 
CASE FALSE 

BY simplification 

BY cases, using (the_month=3) 

CASE TRUE 

BY left substitution of 4 
BY synthesis of TRUE 
CASE FALSE 

BY cases, using (the_month=4) 

CASE TRUE 

BY left substitution of 5 
BY synthesis of TRUE 
CASE FALSE 

BY cases, using (the_month=5) 

CASE TRUE 

BY left substitution of 6 
BY synthesis of TRUE 
CASE FALSE 

BY cases, using (the_month=6) 

CASE TRUE 

BY left substitution of 7 
BY synthesis of TRUE 
CASE FALSE 

BY cases, using (the_month=7) 
CASE TRUE 

BY left substitution of 8 
BY synthesis of TRUE 
CASE FALSE 

BY cases, using (the_month=8) 
CASE TRUE 

BY left substitution of 9 
BY synthesis of TRUE 
CASE FALSE 

BY cases, using (the_month=9) 
CASE TRUE 



104 


APPENDIX E 


— ! BY left substitution of 10 

— ! BY synthesis of TRUE 

— ! CASE FALSE 

— ! BY cases 1 using (the_month = 10) 

— ! CASE TRUE 

— 1 BY loft substitution of 11 

— ! BY synthesis of TRUE 

— ! CASE FALSE 

— \ BY cases, using (the_month = 11) 

— ! CASE TRUE 

— ! BY left substitution of 12 

— ! BY synthesis of TRUE 

— ! CASE FALSE 

— ! BY cases, using (the_month = 12) 

— ! CASE TRUE 

— ! BY left substitution of 13 

— ! BY synthesis of TRUE 

— ! CASE FALSE 

— I BY array simplification 

— ! BY simplification 

— ! BY synthesis of TRUE 

— t n 

IS 


BEGIV 

IF (the_month=(month_name_tic_pos(february)+l)) THE! 

IF is_leap_year(the_year) THEI 

RETURI (days_per_aonth((month_name_tic_pos(f ebmary) + l) ) 

+D; 

ELSE 

RETURI days_per_month(the_month) ; 

END IF; 

ELSE 

RETURI days_per_month(the_month) ; 

END IF; 

EID days_in; 

FUICTI0I month_of (the_month : II month) RETURI month_name 

— I WHERE * * * 

— I II good_month(the_month) ; 

— I RETURI month_name_Bort_tic_val((the_month-l)) ; 

— I EID WHERE; 

— ! VC Status: proved 
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— ! BY synthesis of TRUE 

— I □ 


IS 


BEGII 

RETURI month.name. t i c_ val ( ( the.month- 1 ) ) ; 

EID month.of; 

FUICTIOI month.of (the.month : II month.name) RETURI month. 
~| WHERE * * * 

— | RETURI (month_name_sort_tic_pos(the_month)+l) ; 

— I EID WHERE; 

— ! VC Status: proved 
— ! BY synthesis of TRUE 
— ! □ 

IS 


BEGII 

RETURI (month_name_tic_pos(the_month)+l) ; 
EID month.of ; 

FUICTIOI day.of (the_year : II year; 

the.day : II year.day) RETURI day.name 


WHERE 

GLOBAL first.day : II ; 

II (first_day=tuesday) ; 

II good_year_and_day(the_year, the .day ) ; 

RETURI day.name.of (the.year, the.day) ; 

EID WHERE; 

VC Status: proved 
BY contradiction, in 2 

BY axiom good_year.and.day in trait time.repre sent at ions 
WITH the.year, the.day FOR the.year : Int , 
the.year.day : Int 

substituting for left 
BY contradiction, in 2 
BY axiom first.year in trait sort .names 
WITH FOR 


— ! substituting for left 

— ! BY simplification 

— ! BY axiom day.name in trait time.representations 
— ! WITH 1901, 1 FOR the.year : Int , the.year.day : Int 
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— ! substituting for left 

— I BY axiom days_since_1900_l in trait time_repre sent at ions 
— ! WITH 1901 FOR the_year:Int 

— ! substituting for left 

— ! BY axiom days_since_i900_0 in trait time_representations 
— ! WITH FOR 

— ! substituting for left 

— ! BY claiming (days_in_year(1900)=365) 

— ! BY axiom days_in_year in trait time_representations 
— ! WITH 1900 FOR the_year : Int 

— ! substituting for left 

— ! BY instantiation of axiom leap.year 
in trait time.representations 
“! WITH 1900 FOR the_year : Int 

— ! BY instantiation of axiom non_leap„ centennial in trait 
time_repre sent at ions 
— ! WITH 1900 FOR the_year:Int 

— ! BY left substitution of 6 

— ! BY left substitution of 7 

— ! BY synthesis of TRUE 

— ! THEM 

— ! BY instantiation of axiom day_val_l 
in trait sort_names 
~ ! WITH FOR 

— ! BY simplification 

— ! BY synthesis of TRUE 

— ! □ 


result : day_name := first_day; 
index : integer; 

PROCEDURE increment (the.day ; II OUT day_name; 
offset : II natural) 

— I WHERE 

— I II good_day_name(the_day) ; 

— I II (off set>=0) ; 

— I II (offset<=6); 

— I OUT ( 

the.day 

day_name_sort_increment(II the.day, offset)); 
— | OUT good_day_name(the_day) ; 

— | END WHERE; 

--! VC Status: proved 
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— ! BY simplification 

— ! BY instantiation of lemma day_name_sort_tic_pos_range 
in trait sort_names 

— ! WITH the.day FOR the_day_name : day.name.sort 

— ! BY simplification 

— ! BY axiom day_name_sort_ increment in trait sort_names 
— ! WITH the.day, offset FOR 

the_day_name : day_name_sort , offset : Int 
— ! substituting for left 

— ! BY instantiation of lemma mod_lower in trait Z 
— » WITH 7, (day _name_sort _t ic_pos ( the.day ) +of f s et ) 

FOR m:Int, a: Int 

— ! BY instantiation of lemma mod_upper in trait Z 
— ! WITH 7, (day_name_sort_tic_pos(the_day)+off set) 

FOR m:Int t a: Int 

— ! BY axiom good_day_name in trait sort_names 
— ! WITH 

day_name_sort_tic_val( 

((day_name_sort_tic_pos(the_day)+offset) HOD 7)) FOR 
the_day_name : day_name_sort 
— ! substituting for left 

— ! BY instantiation of lemma day_name_8ort_tic_val_range 
in trait sort_names 
— ! WITH 

( (day_name_sort_tic_po8 (the_day)+off set) HOD 7) FOR 
the_pos : Int 
— ! BY simplification 

— ! BY instantiation of lemma mod_subtract in trait Z 
— ! WITH 7, (day_name_sort_tic_pos(the_day)+off set) 

FOR m:Int, a: Int 
— ! BY simplification 
— ! BY cases, using ( 

(day_name_sort_tic_pos(the_day)+off set) 

< 

7) 

— ! CASE TRUE 

— ! BY lemma mod_ident in trait Z 

— ! WITH (day_name_sort_tic_pos(the_day)+of f set) , 

7 FOR a: Int, m:Int 
— ! substituting for left 

— ! BY simplification 

— ! BY synthesis of TRUE 

— ! CASE FALSE 
— ! BY simplification 
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— ! BY synthesis o f TRUE 
— * □ 


IS 


BEGII 

the.day :=day_naae.tic_val((day_naae_tic_pos(the_day)+ 
offset)) ; 

EXCEPTIOI 

WHEI constraint.error => 
the.day : =day_name_tic_val ( ( 

(day_name_tic_pos(the_day)+offset)-7)) ; 

EJTD increment; 

BEGIV 

index: =(year_tic.f irst()+l ) ; 

— ! VC Status: ** not proved ** 

— ! BY simplification 
— ! BY instantiation of axiom day .name 
in trait time.representations 

— ! WITH (index-1), 1 FOR the.year : Int , the.year.day : Int 

— ! BY instantiation of lemma day_name_sort_tic_val_range in 
trait sort_names 
-- ! WITH 

((days_of_years_since_1900((index-l))+l) MOD 7) FOR 
the.pos : Int 

— ! BY instantiation of lemma aod.upper in trait Z 
— ! WITH 7, (days.of _y ears.s ince.1900 ( ( index-1 ) ) + 1 ) FOR 

a: Int, a: Int 

~! BY instantiation of lemma mod.lover in trait Z 
— ! WITH 7, (days.of_years_since_1900((index-l))+l) FOR 

a: Int, a: Int 

— ! BY axiom good.day.name in trait sort .names 
— ! WITH result FOR the.day.name : day.name.sort 

— ! substituting for left 

— ! BY simplification 
— ! BY synthesis of IF, 

~! 1. (years.tic.f irst<index) 

— ! 2. (index<=(i+the.year)) 

— ! 3. (result=day_name_of ((index-1) , 1)) 

— ! 4. (result 


day_name_sort_tic_val((days_of_years_since_1900( (index-1)) 
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HOD 

7))) 

— ! 5. (0 

<= 

((l+dayB.of.years_since.l900((index-l))) MOD 7)) 

— j g. ( ((i+days.of.y ear s.since. 1900 ((index-1))) MOD 7) 

<= 

6 ) 

— ! 7 , (monday 

<= 

day.name_sort_tic_val( ( ( 1 
+ 

days_of_years.since_1900( (index-1))) 

MOD 

7))) 

— I 8. ( 

day.name_sort_tic_val( ((1 
+ 

days.of_years_since.l900( (index-1))) 

MOD 

7)) 

<= 

Sunday) 

— f 9. (index<=the.year) 

— ! » 

(IF is_leap_year(the_year) 

THEI (good_day_name (day .name. sort.increment (result , 2)) 
-> 

(day.name.sort.increment (result , 2) 

3 

day.name_of( index, 1))) 

ELSE (good.day .name (day.name.sort.increment (result , l)) 
-> 

(day.name.sort.increment (result , 1) 

s 

day .name .of (index, 1)))) 

— ! <proof > 

— ! AID 

— ! BY instantiation of lemma mod.lower in trait Z 
— ! WITH 7, the.day FOR m:Int, a:Int 

— ! BY instantiation of lemma mod.upper in trait Z 

— ! WITH 7, the.day FOR m:Int, a:Int 

— ! BY simplification 
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—I 1. (years_tic_firet<index) 

~l 2. (index<=(l+tlie_year)) 

-f 3. (result=day_najne_of ( (index-1) , 1)) 

- ! 4. (result 


day_name_sort_t ic_ val ( (day s_of _years_since_ 1800 ( ( index- i ) ) 
MOD 
7))) 

— ! 5. (0 


<= 

((i+days_of_years_since_1900( (index-1))) MOD 7)) 

■! 6. (((l+days_of_years_since_1900( (index-1))) MOD 7) 

<= 

6 ) 

• ! 7 . (monday 

<= 


day_name_sort_tic_val(((l 

+ 

days_of_years_since_1900( (index-1))) 

MOD 

7))) 

-! 8 . ( 

day_name_sort_tic_val ( ( ( 1 
+ 

days_of_years_since_1900( (index-!))) 

MOD 

7)) 

<= 

Sunday) 

■! 9. (index>the_year) 

■I 10. (0<=(th.e_day MOD 7)) 

! 11. ((the.day MOD 7)<=6) 

! » ((0<(the_day MOD 7)) 

AID 

( 

good_day _name ( 

day_name_sort_increment (result , ((the.day MOD 7)-l))) 

-> 

(day_name._sort_ increment (result , ((the.day MOD 7)-l)) 

day_name_oi (the.year, the.day)))) 

! <proof> 
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— ! □ 

WHILE (index<=the_year) LOOP 
— | IMVARIAIT ( 

( 

((years_tic_first+l)<=index) 

AMD 

( index<= (the_y ear+ 1 ) ) ) 

AND 

(result=day_name_of ((index-1) , 1))) l 
IF is_leap_year(the_year) THEM 
increment (result , 2); 

ELSE 

increment (result , 1); 

EID IF; 

index := (index* 1) ; 

EID LOOP; 

increment (result , natural_ize(((the_day HOD 7)-l))); 
RETURI result ; 

EID day_of; 

FUICTIOI day_of (the_time : II time) RETURI year.day 

— | WHERE * ♦ * 

— | II good_time(tlie_time) ; 

—| RETURI day_of_year(the_time.the_year, 

the.time.the_month, the_time . the_day) ; 

— | EID WHERE; 

— ! VC Status: proved 
— ! BY simplification 

— ! BY instantiation of axiom day s_since_ January _0 
in trait time_representations 
— ! WITH the_time . the.year FOR the.year : Int 

— ! BY instantiation of axiom months_tic_f irst 
in trait sort_names 
— ! WITH FOR 

— ! BY simplification 
— ! BY simplification 
— ! BY contradiction, in 1 

— \ BY axiom good_time in trait time^r ©present at ions 

— * WITH the.time FOR the_time: AnyRecordSort 

— ! substituting for left 

— ! BY contradiction, in 1 

— ! BY simplification 
— ! BY synthesis of TRUE 
— ! □ 
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IS 

result : natural : — 0 ; 
index : month; 

BEGII 

index :=month_tic.first() ; 

— f VC Status: proved 
— ! BY simplification 
— ! BY contradiction, in 2 

— f BY axiom good.time in trait time.representations 
WITH the.time FOE the.time : AnyRecordSort 
— ! substituting for left 

— ! BY contradiction, in 2 
— ! BY simplification 

— I BY synthesis of IF, 

— ! BY axiom days, since. January. 1 

in trait time.representations 

— I WITH (1+index), the.time .the.year FOR the.month: 

Int, the.year: Int 

— ! substituting for left 

! BY instantiation of lemma daye.in.month.range in trait 
time.representations 

— ! VITH index, the.time. the.year FOR the.month: Int , 

the.year: Int 
— ! BY simplification 

— ! BY axiom good_month in trait time.representations 

— t WITH index FOR the_aonth : Int 

”1 substituting for left 

— ! BY instantiation of axiom months.tic.first 
in trait sort.names 
“ f WITH FOR 

— ! BY simplification 

— ! BY simplification 

— ! BY axiom good.year in trait time.representations 

— i WITH the_time.the.year FOR the.yearrlnt 

— ! substituting for left 

— ! BY simplification 

— ! BY synthesis of TRUE 

— ! AID 

— ! BY instantiation of lemma days. since. January .positive 
in trait time.representations 

“* WITH index, the.time. the.year FOR the_month : Int , 

the_year:Int 
— ! BY simplification 
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— ! BY axiom day. of .year in trait time.representations 
— j WITH the.t ime. the.year, index, the.time . the.day 

FOR the.year : Int , the.month : Int , the.montli.day : Int 
— ! substituting for left 

— ! BY simplification 

— ! BY instantiation 

of lemma day s.since. January .upper .bound 
in trait time.representations 

— i WITH index, the.time . the.year FOR the.month : Int , 

the.year : Int 

— ? BY instantiation of axiom good_month 

in trait time.representations 
~j WITH index FOR the.month: Int 

— ! BY instantiation of axiom good.year 

in trait time.representations 

— I WITH the.time. the.year FOR the.year: Int 

— ! BY instantiation of lemma days.in.month.range in trait 

time.representations 

— j WITH the.time. the.month, the.time .the.year FOR 

the.month: Int , the.year: Int 

— ! BY simplification 

— ! BY synthesis of TRUE 

— ! □ 

WHILE (index<=(the.time.the_month-i)) LOOP 
— | INVARIANT C 
( 

( 

(result=days_since.Jan(index, the.time. the.year)) 

AND 

good.t ime ( the.t ime ) ) 

AND 

(months.tic.f irst<=index)) 

AND 

( index<=the.t ime . the.month) ) ; 
result : =(result+ 

natural.ize( days. in (index, the.time. the.year))) ; 
index :=(index+l) ; 

END LOOP; 

RETURN year.day.ize ( (result+natural.ize C the.t ime . the.day ) ) ) ; 
END day.of; 

FUNCTION time.of (the.year : IN year; 
the.day : IN year. day) RETURN time 

— | WHERE * + * 

—| IN good.year.and.day (the.year, the.day); 
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— I RETURF t SUCH THAT ( 

( 

( 

( 

c 

( 

(t . the_year=the_year) 

AID 

(t . the_month=montli_of (the_year , the_day ) ) ) 

AID 

(t . the_day=day_of_month(the_year, the_day))) 

AID 

(t . the_hour=0) ) 

AID 

(t . the_minute=0) ) 

AID 

(t . the_second=0) ) 

AID 

(t . the_millisecond=0) ) ; 

-I EID WHERE; 

-! VC Status: proved 

-! BY axiom months_tic_f irst in trait sort^names 

- I WITH FOR 

-! substituting for left 

- ! BY axiom months_tic_last in trait sort_names 

- ! WITH FOR 

-! substituting for left 

-! BY contradiction, in 1 

-! BY axiom goodly ear_and_day in trait time_representations 
*? WITH the_year, the_day FOR the.year : Int , 

the_year_day : Int 
! substituting for left 

! BY contradiction, in 1 
! BY simplification 

! BY axiom good_year in trait time_representations 
! WITH the_year FOR the_year:Int 

! substituting for left 

! BY simplification 

! BY axiom good„month in trait time.representations 
! WITH 1 FOR the_month : Int 

! BY lemma days_in_montli_range 

in trait time_representations 
! BY analysis of FORALL, in 5 

! WITH 1, the_year FOR the_month: Int , the_year : Int 
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— ! BY simplification 
— ! BY axiom daye_since_January_0 

in trait time.representations 
— ! WITH the_year FOR the_year :Int 

— I substituting for left 

— ! BY instantiation of lemma days..in_year_identity 
in trait time.representations 
— ! WITH the_year FOR the_year:Int 

— ! BY instantiation of axiom months _tic_last 
in trait sort_names 
— ! WITH FOR 

— ! BY simplification 
— ! BY synthesis of TRUE 
— ! □ 

IS 

result : year_day := the_day; 
temp : time; 
index : month ; 

BEGIH 

index : =month_t ic_f irst ( ) ; 

— ! VC Status: proved 
— ! BY simplification 

— ! BY instantiation of lemma days_in_month_range 
in trait time_representations 

— ! WITH index, the_year FOR the_month : Int , the_year:Int 

— ! BY simplification 

— \ BY axiom good.month in trait time.representations 

— ! WITH index FOR the_month : Int 

— ! substituting for left 

— ! BY simplification 

— ! BY axiom months_tic_f irst in trait sort_names 
— ! BY axiom months_tic_last in trait eort_names 
— ! BY simplification 
— ! BY simplification 
— ! BY synthesis of IF, 

— ! BY instantiation of axiom month.of 

in trait time.representations 

I WITH index, the_year, the_day FOR the_month : Int , 

the_year : Int , the_year_day : Int 
— ! BY simplification 

— ! BY axiom day_of_month in trait time_repre sent at ions 

— i WITH the_year, the_day FOR the_year : Int , 
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the.y ear.day : Int 

— ! substituting for left 

— I BY simplification 

— I BY axiom first Jiour in trait sort.names 
— ! BY axiom first_minute in trait sort .names 

• BY axiom first.second in trait sort_names 

— ! BY axiom first.millisecond in trait sort .names 

— ! BY simplification 

— ! BY simplification 

— ! BY synthesis of TRUE 

— ! AID 

— ! BY instantiation of axiom days.s ince. January. 1 
in trait time.representations 

— I WITH (1+ index) , the.year FOR the.month : Int , 

the.year : Int 

— ! BY simplification 

— ! BY synthesis of TRUE 

“! □ 

WHILE (index<=month.tic.last()) LOOP 
— I IIVARIAIT ( 

( 

( 

((days.since^Jan(index, the.year) +result)=the_day) 

AID 

( 

( 

(months_tic.first<=index) 

AID 

(index<=months_tic.last)) 

AID 

good.y ear (the.year) ) ) 

AID 

(result>0)) 

AID 

( 

the.day 

<= 

( 

days. since. Jan(months_tic.last , the.year) 

+ 

days. in.month (months. t ic.last , the.year ) ) ) ) ; 

IF (result<=year.day_i 2 e(days.in(index l the.year))) THEI 
temp . the.year : ^the.year ; 
temp . the.month : = index ; 
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temp . the.day : =day_ize (result ) ; 

temp. the.hour : =hour_t ic_f irst() ; 

temp. the _minute : =minute_tic..fir8t() ; 

temp . the.second : =second_t ic.f irst () ; 

temp . the.millisecond : =millisecond_t ic.f irst () j 

RETURI temp; 

ELSE 

result : = (result-y ear.day.ize (days_in( index , the.y ear ) ) ) ; 
EID IF; 

index :=(index+l) ; 

EID LOOP; 

RAISE lexical.error; 

EID time.of; 

FUICTIOI period.of (the.time : II time) RETURI period 

— | WHERE 

— | GLOBAL noon : II ; 

— | II (noon=12) ; 

— I II good_time(the_time) ; 

— | RETURI (IF (the.t ime . the_hour<12) THEI am ELSE pm); 

— | EID WHERE; 

— i VC Status: proved 
— ! BY simplification 
— ! BY synthesis of TRUE 
— ! □ 


IS 


BEGII 

IF (the.time . the _hour>=noon) THEI 
RETURI pm; 

ELSE 

RETURI am; 

EID IF; 

EID period.of; 

FUICTIOI time.of (the.time : II time) RETURI calendar .time 
— | WHERE 

— | GLOBAL seconds.per.hour , seconds.per .minute, 

milliseconds.per.second : II ; 

— | II good.time(the.time) ; 

— | RETURI time_to_cal_time( the. time) ; 

— | EID WHERE; 

— ! VC Status: ** not proved ** 

— ! BY contradiction, in 1 
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! BY axiom good.time in trait time.representations 
• WITH the.time FOR the.time: AnyRecordSort 

— ! substituting for left 

— ! BY contradiction, in 1 
— ! BY analysis of AMD, in 1 

— ! BY instantiation of lemma days_in_month.range 
in trait time.representations 
— ! WITH the.t ime . the.month , the.time. the.y ear FOR 

the.month: Int , the.y ear : Int 

— I BY simplification 

— ! BY axiom good.year in trait time.representations 

— I WITH the.time . the.y ear FOR the_year:Int 

— ! substituting for left 

— ! BY axiom good.month in trait time_representations 
"* ! WITH the.time . the.month FOR the.month: Int 

— ! substituting for left 

! BY axiom good.month.day in trait time.representations 
! WITH the.time . the. day FOR the.month.day : Int 

— ! substituting for left 

— ! BY simplification 

— ! BY claiming ( 

days_in.month( the.time . the.month , the.time . the.year) 

<= 

31) 

— ! BY hypothesis 

— ! THEM 

— \ BY simplification 

— ! 1. (1901<=(the.time. the.year)) 

— ! 2. ((the.time. the.year )<=2099) 

— ! 3, (0<(the.time. the_month)) 

— f 4. ((the.time. the _jnonth)<=12) 

— ! 5. (Q<(the_time.the.day)) 

— ! 6. ( (the.t ime.the.day) 

<= 

days. in .month( (the.time . the.month) , (the.time . the.year) ) ) 
— ! 7, (0<=(the.time. the_hour)) 

— ! 8. (( the.t ime.the_hour)<days.to.hours) 

— ! 9. (0<=(the.time.the .minute)) 

— ! 10 . ( (the. time . the_minute)<hours_to .minutes) 

— ! 11. (Q<= (the.time. the. second)) 

— ! 12. ((the.time. the.second)<minutes.to.seconds) 

— ! 13. (0<= (the.t ime.the_millisecond)) 

— ! 14. ((the. time, the billisecond) 

< 
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seconds_to_milliseconds) 

— ! 15 . ( 

day8_in.jiionth( (the_time . the_month) , (tlie_tiine . the.yaar ) ) 
<= 

31 ) 

— ! 16 . 

good_duration( 

seconds_to_duraticm( ( (the_time . tho.millisecond) 

/ 

milliseconds_per_second) ) ) 

— ! 17 . 

good.durat ion ( s econds_to w durat ion ( ( the_t ime . the_8 econd) ) ) 
--! 18 . 

good_dur at ion ( 

seconds_to_duration( ( (the_time . the_minute) 

* 

seconds_per_mimite) ) ) 

— ! 19 . 

good_durat ion ( 

seconds_to_duration( ( (the_time . the_hour) 

* 

seconds_perJiour ) ) ) 

— ! 20 . 

good_duration( ( 

B6conds_to_dnration( ( (th.e_time . the_minute) 

♦ 

seconds_per_minute) ) 

+ 

seconds_to_durat ion( ( (the.time . the_houx) 

* 

8«conds_per_hour) ) ) ) 

— ! 21 . 

good_durat ion ( ( ( 

s e conds _to_dur at ion ( ( ( the_t ime . the_hour ) 

* 

8econd8_per_hour) ) 

+ 

seconds_to_duration( ( (the_t ime . the.minute) 

* 

8econds_pei\jainute) ) ) 

+ 

seconds_to_duration( (th.«_time . the_second) ) ) ) 
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— ! 22 . 

good.dur at ion ( ( ( ( 

seconds_to_duration( ( (the.time . the_hour) 

* 

seconds_per_hour) ) 

+ 

seconds_to_duration( (the.time . the.second) ) ) 

+ 

seconds_to_duration( ( (the.time . the_minut e) 

* 

seconds.per .minute) ) ) 

+ 

seconds_to_duration( ( (the.time . the_millisecond) 

/ 

milliseconds.per.second) ) ) } 

— I » < 

good_date( (the.time . the.year) , 

(the.time.thejnonth) , 

(the.time.the.day) , 

((( 

8econd8_to_duration( ( (the.time . the.hour) 

* 

seconds.per.hour) ) 

+ 

8econd8_to_duration( (the. time . the. second) ) ) 

+ 

seconds.to.durationC ( (the.time . the.minute) 

* 

seconds^ per_minut e ) ) ) 

+ 

seconds.to.durationC ( (the.time . the.millisecond) 

/ 

milliseconds.per.second) ) ) ) 

AID 

( 

t ime.of ( (the.time . the.year) , 

(the.time. the.month) , 

(the.time . the.day ) , 

((( 

seconds.to.durationC ( (the. time . the.hour) 
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seconds.per.hour) ) 

+ 

seconds_to_duration( (the.time . the.second) ) ) 

+ 

seconds_to_duration( ( (the.time . the.minute) 

* 

seconds.per.minute) ) ) 

+ 

seconds.to.durat ion( ( (the.time . the .millisecond) 

/ 

milliseconds.per.second) ) ) ) 

time.to.cal.time (the.time) ) ) 

— ! <proof> 

— ! □ 

IS 

BEGII 

RETURI calendar . t ime.ol (year.number.ize (the.time . the.y ear ) , 
month.number.ize (the.time . the_month) , 
day.number.ize (the.time . the.day) f 
( 

( 

( 

calendar .day.durat ion.ize (( 

integer.ize (the.time . the.hour)* 
seconds.per.hour) )+ 
cal endar . day _dur at ion. ize ( ( 

integer.ize (the.time . the.minute) * 

0 e conds .per .minut e ) ) ) + 

calendar . day.durat ion.ize (the.time . the.second) ) + 
calendar . day.durat ion.ize ( (the.time . the.milli0econd/ 
milliseconds.per.second) ) ) ) ; 

EID time.ol; 

FUICTIOI time.oi (the.time : II calendar .time) RETURI time 

— I WHERE 

— I GLOBAL seconds.per.hour, seconds. per. minute, 

milliseconds.per.second : II ; 

— | RETURI cal.time.to.time (the.time) ; 
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--I EID WHERE; 

— ! VC Status: hidden 
— ! □ 


IS 

result : time; 

total_duration : calendar .day _durat ion; 

seconds ; natural; 

the_year : year; 

the_month : month; 

the_day : day; 

BEGIV 

calendar . split (the.time , 
the_year t 
the^month, 
the_day , 

total_duration) ; 

— To mollify our aggressive aliasing checks; 
result . the_y ear : = the_ysar ; 
result . the_month : =the_month; 
result . the_day : =the_day ; 

— ! PRECOHDITIOI * (good_duration(total_duration) 

AMD 

( C (0<= (Floor (total_durat ion) /seconds _per_hour)) 

AID 

( (Floor (total_duration)/seconds_per_hour)<24)) 

AID 

(((0 

<= 

( (Floor (total_duration) HOD seconds_per_hour) 

/ 

seconds_per_minute) ) 

AID 

(( (Floor (total.durat ion) MOD seconds_per_hour) 
s e conds _per_minut e ) 

< 

60 )) 

AID 

(((0 

<= 

((Floor(total.duration) MOD seconds_per_hour) 
MOD 
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seconds _per_minute) ) 

AID 

(( (Floor (total.duration) MOD seconds _per_hour) 

MOD 

seconds_per_minute) 

< 

60)) 

AID 

(good_duration(total_duration) 

AID 

( (good_duration(RealPart (total_duration) ) 

AID 

good_duration( (Real Part (total_durat ion) 

♦ 

millisecond8_per_second) ) ) 

-> 

( ( ( ( (result C . the Jhour 

=> (Floor (total_durat ion) 

/ 

seconds_per_hour)] ) [.the_minute 
=>( (Floor (total_duration) 

HOD 

seconds_per_hour) 

/ 

seconds .per .minute)] ) [.the_second 
=>( (Floor (total_duration) 

HOD 

s e conds _per .hour ) 

MOD 

s e conds _per_ minute)] ) [. the_millisecond 

=> 

Floor ((1000 

* 

(RealPart (total_durat ion) 

* 

milliseconds_per_second) ) )] ) 

cal_time_to_time(the_time) ) )))))); 
seconds : =duration_utilities . floor(total_duration) ; 
result .the_hour: =hour_ize((seconds/seconds_per_hour)) ; 
seconds := (seconds HOD seconds_per_hour) ; 

result . the_minute : =minute_ize( (seconds/se conds _per_minute) ) ; 
result .the_second;=second_ize ((seconds HOD 
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seconds.per.minute) ) ; 
result . the.millisecond : =millisecond.ize( ( 

duration.utilities .real.part(total.duration)* 
milliseconds.per.second)) ; 

RETURI result ; 

END time.of; 

FUNCTION duration.of (the. interval : IN interval.) RETURN built in 
.duration 

— I WHERE 

— | GLOBAL seconds.per.day, seconds _per_hour , 

seconds. per .minute : IN ; 

— I IN (seconds_per_hour=hours.to.6econds) ; 

— I IN (seconds.per.minute^minutes.to.seconds) ; 

— I IN (seconds.per.day^days.to.seconds) ; 

— I IN good. interval (the.interval) ; 

— I RETURN interval.to.duration(the.interval) ; 

— I RETURN result SUCH THAT good.durat ion (result) ; 

— I END WHERE; 

— ! VC Status: proved 
— ! BY axiom Int.identity in trait Z 

— ! WITH (the. interval. elapsed_days*days_to_seconds) 

FOR n:Int 

— ! substituting for left 

— ! BY lemma seconds.to.duration in trait sort_names 
— ! WITH (the. interval. elapsed.days+seconds.per.day) 

FOR the.second: Int 
— i substituting for left 

— ! BY simplification 

— 4 BY instantiation of lemma good.duration.pair 
in trait time.representation^conversions 
— ! WITH (seconds_per_day*the.interval.elapsed.days) , i 

FOR n:Int, d:Int 
— ! BY simplification 

— ! BY axiom good.second in trait sort.names 
— ! WITH ( the. int erval. elapsed.milliseconds/ 1000) FOR 

the.second: Int 

— ! substituting for left 

— ! BY instantiation of axiom good.interval 
in trait sort.names 

— ! WITH the.interval FOR the.interval: AnyRecordSort 

— ! BY contradiction, in 4 
— ! BY left substitution of 7 
— ! BY contradiction, in 4 
— ! BY analysis of AND, in 4 
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— ! BY instantiation of axiom good w millisecond 
in trait sort.names 

— ! WITH the_interval. slaps ed.milliseconds FOR 

the_millisecond : Int 
— ! BY contradiction, in 11 
— ! BY loft substitution of 12 
— ! BY contradiction, in 11 

— ! BY claiming ((the_interval .elapsed_milliseconds/1000)=0) 
— ! BY lemma div_upper in trait Z 

— ! WITH the.interval.elapsed.milliseconds, 1000 FOR 

a: Int, m:Int 

— ! substituting for left 

— ! BY hypothesis 

— ! THEM 

— ! BY simplification 

— ! BY synthesis of TRUE 

— ! □ 


IS 

temp : built in. duration; 

BEGIV 

temp : =built in . duration_ize ( ( 

int eger_ize(the_ interval . elapsed_days)*seconds_per_day)) ; 

— ! VC Status : proved 

— ! BY lemma pair_minus in trait fixed_point 
— ! WITH 

( 

Int_identity( (the_ interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the_interval . elapsed_hours*hours_to_seconds) ) ) , 1 , 
(the_interval. elapsed_hours*seconds_per_hour) , 1 FOR nl: 

Int, dl:Int, n2:Int, d2:Int 
— ! substituting for left 

— \ BY axiom Int_identity in trait Z 
— ! WITH 

( 

Int_identity ( (the.interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the_interval.elapsed_hours*hours_to_seconds))) FOR n: 

Int 

— ! substituting for left 
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— ! BY axiom Int. identity in trait Z 

— ! WITH (the_interval , elapsed.hours*seconds_per_hour) 

FOR mint 

— ! substituting for left 

— ! BY axiom Int. identity in trait Z 

— ! WITH (the_interval . elap8ed_hour8*hours_to_8econds ) 

FOR n: Int 

— ! substituting for left 

— ! BY axiom Int. identity in trait Z 

— ! WITH (the.interval . elapsed.days+days.to.seconds) 

FOR mint 

— ! substituting for left 

— ! BY contradiction, in 1 
— ! BY axiom Int_identity in trait Z 

— ! WITH (the_ interval. elapsed.days*days_to_8econds) 

FOR n: Int 

— I substituting for left 

— I BY contradiction, in I 
— ! BY simplification 

— I BY synthesis of TRUE 

— I □ 

— I ASSERT ( 

( 

( 

temp 

pair( 

Int.identity( 

(the.interval. elapsed.days+days.to.seconds)) ,1)) 

AID 

good. int erval (the. interval) ) 

AID 

( 

( 

good.durat ion (temp) 

AID 

( 

good.interval(the.interval) 

AID 

good.second( 

(the.interval . elapsed.milliseconds/ 1000) ) ) ) 

AID 

( 

(seconds.per.hour=hour8.to_seconds) 
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AID 

(seconds_per.minute=minute8_to_seconds) ) ) ) ; 

— ! USE lemma subtract. duration, equals II TRAIT 
time.representation.conversions 

WITH 

temp, 

pair( 

( 

Int.identity( 

(the_interval.elapsed_days*days_to.seconds)) 

+ 

Int.identity( 

( the. interval. elapsed_hours*hourB_to_Beconds))) , 

1). 

pair((the.interval.elapsed_hours*seconds.per_hour) , 1) 
FOR 

m: AnyRecordSort , n: AnyRecordSort , p : AnyRecordSort 
— ! substituting lor lelt; 

— ! USE lemma good.duration.pair II TRAIT 
time.representation.conversions 

WITH 

(the_ interval . elapsed.hours*seconds_per.hour) , 1 
FOR 

n:Int, d:Int; 

— ! USE lemma good.duration.sum II TRAIT 
time.representation.conversions 

WITH 

temp, 

pair ( (the.interval . elapsed_hours*8econd8_per_hour) , 1) 
FOR 

dl : AnyRecordSort , d2 : AnyRecordSort ; 

— ! USE lemma seconds.to.duration II TRAIT Bort.names 

WITH 

(the. interval . elapsed.hours* seconds. per .hour) 

FOR 

the.second : Int 
— ! substituting lor lelt; 
temp:=(temp+ 

built in . duration. ize ( ( 

integer.ize( the. interval, elapsed.hours)* 


128 


APPENDIX E 


seconds_per_hour) ) ) ; 

— ! VC Status: proved 

— ! BY lemma pair_minus in trait fixed_point 
— ! WITH 

( 

c 

Int_identity( 

(the.interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the_ interval . elapsed_hours*liours_to_ seconds) ) ) 

+ 

Int_identity( 

(the_interval . elapsed_jninutes*minutes_to_seconds) ) ) , 

1, (th.e__ interval . elap8ed_minutes*seconds_per .minute) , 1 
FOR nl:Int, dl:Int, n2:Int, d2:Int 
— ! substituting for left 

— 1 BY axiom Int. identity in trait Z 

— ! WITH 

( 

( 

Int_identity( 

(the_interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the. interval . elapsed.hours*hours.to_seconds) ) ) 

+ 

Int_identity( 

(the .interval . elapsed.minutes*minutes_to_seconds) ) ) 

FOR n:Int 

— ! substituting for left 

— ! BY axiom Int.identity in trait Z 
— ! WITH 

(the.interval. elapsed_minutes*seconds_per .minute) FOR n:Int 
— ! substituting for left 

— ! BY axiom Int.identity in trait Z 
— ! WITH 

(the.interval. elapsed_ainutes*minutes.to_seconds) FOR n:Int 
— ! substituting for left 

— ! BY axiom Int.identity in trait Z 

— ! WITH (the.interval. elapsed_hours*hours.to.seconds) 

FOR n:Int 

— ! substituting for left 

— ! BY axiom Int.identity in trait Z 
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— f WITH (the.interval . elapsed.days*days_to_seconds) 

FOR n:Int 

— ! substituting for left 

— ! BY contradiction, in 1 

— ! BY axiom Int_identity in trait Z 

— ! WITH (the.interval . elapsed.days*days_to_seconds) 

FOR n:Int 

— ! substituting for left 

— ! BY axiom Int.identity in trait Z 

— ! WITH (the.interval . elapsed_hours*hours_to_seconds) 

FOR nrlnt 

— ! substituting for left 

— ! BY simplification 
— ! BY synthesis of TRUE 
— ! □ 

— I ASSERT ( 

( 

( 

temp 

pair( 

( 

Int.identityf 

(the.interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the.interval . elapsed_hours*hours_to_seconds) ) ) , 

1 » 

AMD 

good. interval (the. interval) ) 

AID 

( 

( 

go od_dur at i on ( t emp ) 

AID 

(seconds.per.minute=minutes.to.seconds)) 

AID 

C 

good. int er val ( the_ int erval ) 

AID 

good_second( 

(the.interval . elapsed.milliseconds/1000) ) ) ) ) ; 

— ! USE lemma subtract.durat ion. equals II TRAIT 
time.representation.conversions 
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VITH 

temp, 

pair( 

( 

( 

Int_identity( 

(the_ interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the.interval . elapsed_hours*hours_to_seconds) ) ) 

+ 

Incident it y( 

( 

the.interval . elapsed.minutes 

* 

minutes.to.seconds))) , 1), 

pairC 

(the ..interval . elapsed_minutes*8econd8_per_minute) , 

1) 

FOR 

m: AnyRecordSort , n: Any Re cordS ort # p: AnyRecordSort 
— ! substituting lor left; 

— ! PRECOIDITIOI » (good^duration(temp) 

AID 

( good.dur at i on ( t emp ) 

AID 

((((temp 

+ 

pair ( ( (the. interval . elapsed.minut es) 

* 

seconds_per_ainute) , 

D) 


pair((( 

Int.identity ( ( (the.interval . elapsed.days) 

* 

days.to.seconds) ) 


Int.identity ( ( (the.interval . elapsed.hours) 

* 
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hours.to.seconds) ) ) 

+ 

Int .identity ( ( ( the . interval . elapsed.minutes) 
* 

minutes.to.seconds))) , 

D) 

AID 

good.interval (the.interval)) 

AID 

(good.interval (the .interval) 

AID 

good_second( ( (the. interval . elapsed_milliseconds) 

/ 

1000 )))))); 

— ! USE lemma good.duration.pair II TRAIT 
t ime.repres entat ion.conver s ions 

WITH 

(the. interval . elapsed_minutes*seconds.per_minute) , 1 
FOR 

n:Int, d:Int; 

— ! USE lemma good.duration.sum II TRAIT 
t ime.repres entat ion.convers ions 

WITH 

temp, 

pair( 

(the.interval . elapsed_minutes*second6_per_minute) , 

1) 

FOR 

dl : AnyRecordSort , d2 : AnyRecordSort ; 

— f USE lemma seconds.to.duration II TRAIT sort_namee 

WITH 

(the.interval . elapsed.minutes+seconds .per .minute) 

FOR 

the.second: Int 
— ! substituting ior left; 
temp: =(temp+ 

builtin . durat ion.ize ( ( 

int eger.ize (the.interval . elapsed.minutes)* 
seconds.per.minute))) ; 


132 


APPENDIX E 


— ! VC Status: proved 

— ! BY lemma pair_minus in trait fixed.point 
— ! WITH 

( 

( 

( 

Int.identity( 

(the. interval. elapsed_days*days_to.seconds)) 

+ 

Int.identity( 

(the.interval. elapsed.hours*hour8.to.seconds) )) 

+ 

Int_identity( 

(the. interval . elapsed_minutes*minut es.to. seconds ) ) ) 

+ 

Int. identity (the.interval . elapsed.seconds) ) , i , 
the.interval. elapsed.seconds, 1 FOR nl:Int, dl:Int, n2: 
Int, d2:Int 

— f substituting for left 

— ! BY axiom Int.identity in trait Z 
— ! WITH 

( 

( 

( 

Int.identity( 

(the.interval . elapsed_days*days_to_ seconds) ) 

+ 

Int_identity( 

(the.interval . elapsed.hours*hours_to. seconds) ) ) 

+ 

Int.identity ( 

(the.interval , elapsed_minutes*minutes_to_seconds) ) ) 

+ 

Int. identity (the.interval. elapsed.seconds)) FOR n:Int 
— ! substituting for left 

— ! BY axiom Int.identity in trait Z 

— ! WITH (the.interval . elapsed_days*days_to.seconds) 

FOR n:Int 

— f substituting for left 

— ! BY axiom Int.identity in trait Z 

— ! WITH (the.interval . elapsed.hours*hours.to_seconds) 

FOR n:Int 

— ! substituting for left 

— ! BY axiom Int.identity in trait Z 
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— ! WITH 

(the_ interval . elapsed.minutes+minutes.to.seconds) FOR mint 
— ! substituting lor left 

— ! BY axiom Int.identity in trait Z 
— ! WITH the.interval. elapsed.seconds FOR mint 

— * substituting lor lelt 

— ! BY contradiction, in 1 

— ! BY axiom Int.identity in trait Z 

— ! WITH (the. interval . elapsed_days*days.to_seconds) 

FOR mint 

— ! substituting lor lelt 

— ! BY axiom Int.identity in trait Z 

— ) WITH (the.interval . elapsed.hours+hours.to.seconds) 

FOR n: Int 

1 — ! substituting lor lelt 

— ! BY axiom Int. identity in trait Z 
— ! WITH 

(the. interval . elapsed.minutes*minutes.to_seconds) FOR mint 
— ! substituting lor lelt 

— ! BY simplilication 
— ! BY synthesis ol TRUE 
— ! □ 

— | ASSERT ( 

( 

( 

temp 

pair( 

( 

( 

Int.identity( 

(the.interval . elapsed.days*days.to_seconds) ) 

+ 

Int_identity( 

(the.interval . elapsed.hours*hours_to.seconds) ) ) 

+ 

Int.identity( 

( 

the.interval . elapsed.minutes 

♦ 

minutes.to.seconds) ) ) , 1) ) 

AID 

(good. interval (the.interval) AHD good.duration(temp))) 

AID 
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( 

good. in t erval ( the.int erval ) 

AID 

good.second(( the. interval. elapsed.milliseconds/1000) ) )) ; 
— ! USE lemma subtract.duration.equals II TRAIT 
t ime.repr esent at ion. conversions 

WITH 

temp, 

pair( 

C 

( 

( 

Int.identity( 

(the.interval . elapsed_days*days.to_seconds) ) 

+ 

Int.identity ( 

( 

the. interval . elapsed.hours 

* 

hours.to.seconds) ) ) 

+ 

Int_identity( 

( 

the.interval . elapsed.minutes 

* 

minutes.to.seconda))) 

+ 

Int.identity (the.interval. elapsed.seconds)) , 1) , 
pair (the.int erval . elapsed.seconds , 1) 

FOR 

m :AnyRe cordSort , n: AnyRecordSort , p : Any Re cordS or t 
— ! substituting for left; 

— ! USE lemma good.duration.pair II TRAIT 
t ime.repre s ent at ion.con ver s ions 

WITH the.interval. elapsed.seconds, 1 FOR n:Int» d:Int; 
<8tatement> 

— ! USE lemma good.duration.sua II TRAIT 
t ime_r epres ent at ion.conver s ions 

WITH 

temp, pair (the.int erval. elapsed.seconds, 1) 

FOR 

d 1 : Any Re cordSort , d2 : AnyRe cordSort ; 
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— ! USE lemma seconds.to.duration II TRAIT sort_names 
WITH the_interval.elapsed_seconds FOR the_sscond:Int 
— ! substituting lor left; 
temp:=(temp+ 

built in . durat ion.ize ( the_int erval . slaps sd^ssconds) ) ; 

— ! VC Status: ** not proved ** 

— ! BY left substitution of 1 
— ! BY axiom Int. identity in trait Z 
— ! WITH 

( 

( 

( 

Int_identity( 

(the.interval . slapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the_interval.elapsed_hours*hours_to_seconds))) 

+ 

Int_identity( 

(the_ interval « elapsed..minutes*minutes_to_second8) ) ) 

+ 

Int_identity(the_interval. elapsed.seconds)) FOR n:Int 
— ! substituting for left 

— ! BY axiom Int.identity in trait Z 
— ! WITH 

( 

( 

C 

( 

( 

Int_identity( 

(the_ interval . elapsed_days*days_to_seconds) ) 

+ 

Int_identity( 

(the_interval.elapsed_hours*hours_to_seconds))) 

+ 

Int_identity( 

( 

the_interval . slaps ed.minutes 

* 

minutes.to.seconds) )) 

+ 

Int_identity(the_ interval . elapssd.seconds) ) 
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1000) 

+ 

Int.identity (the.interval. elapsed.milliseconds) ) FOR n: 
Int 

— ! substituting for left 

— ! BY claiming ( 

Int_identity( 

((the.interval. elapsed.millisecond8/1000)*1000)) 

Int.identity (the.interval . elapsed.milliseconds) ) 

— ! BY axiom Int.identity in trait Z 
— ! WITH 

((the.interval. elapsed_milliseconds/1000)*1000) FOR n:Int 
— I substituting for left 

-r! BY axiom Int.identity in trait Z 

— ! WITH the.interval. elapsed.milliseconds FOR mint 

— ? substituting for left 

— ! 1. (temp 


pair(( ( ( 

Int_identity ( ( (the.interval . elapsed.days) 

♦ 

days.t o.seconds ) ) 

+ 

Int.identity ( ( (the. interval . elapsed.hours) 

* 

hours.to.seconds) ) ) 

+ 

Int. identity (( (the.interval . elapsed.minutes) 

* 

minutes.to.seconds) ) ) 

+ 

Int.identity ( (the.interval . elapsed.seconds) ) ) , 

«) 

— ! 2. good.interval (the.interval) 

— ! 3. good.duration(temp) 

— ! 4. 

good_second( ( (the.interval . elapsed.milliseconds)/l000) ) 

— ! » ( ( ( (the.interval . elapsed_milliseconds)/1000) *1000) 

(the.interval . elapsed.milliseconds)) 
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— ! <proof > 

— ! THE! 

— ! BY claiming ( 

pair( 

( 

( 

( 

Int.identity( 

(the. interval . elapsed.days*day8.to_Becond8) ) 

+ 

Int_identity( 

(the. interval . elapsed.hours+hours.to.seconds) ) ) 

+ 

Int.identity( 

(the.interval. elapsed.minute8*minute8.to_Beconds))) 

+ 

Int. identity (the. interval. elapsed.seconda)) , 1) 

pair( 

( 

( 

( 

( 

Int.identity( 

(the. interval . elapsed.days*days.to_seconds) ) 

+ 

Int.identity( 

(the.interval . elapsed_hourB*hours_to_seconds) ) ) 

+ 

Int_identity( 

( 

the.interval . elapsed.minutes 

* 

minutes.to.seconds) ) ) 

+ 

Int_identity(the_interval.elapfled.second8)) 

* 

1000), 1000)) 

— ! BY lemma concrete.equality.pair 

in trait fixed.point 
— ! WITH 

( 

( 


( 
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Int.identityC 

(the. interval. elapsed_days*days_to_seconds)) 

+ 

Int_identity( 

(the. interval , elapsed_hours*hours_to_seconds) ) ) 

+ 

Int_identity( 

(the.interval . elapsed _»inutes*minuteB_to_ seconds) ) ) 

+ 

Int.identity (the.interval . elapsed. seconds) ) , l § 

( 

( 

( 

c 

Int.identity( 

(the. interval . elapsed_days*days.to. seconds) ) 

+ 

Int.identityC 

(the.interval . elapsed_hours*hours_to_seconds) ) ) 

+ 

Int.identityC 

(the.interval . elapsed_minutes*minutes_to_seconds) ) ) 

+ 

Int. identity (the_interval . slaps ed.seconds) ) 

* 

1000), 1000 FOR nl : Int , di:Int, n2:Int, d2:Int 
! substituting lor left 

! BY synthesis of TRUE 

! THEI 

! BY left substitution of 5 

! BY simplification 

I BY synthesis of TRUE 

! □ 

I ASSERT ( 

( 

( 

( 

temp 

pair( 

( 

( 

( 


Int_identity( 
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( 

the.interval . elapsed_days 

* 

days.to.seconds) ) 

+ 

Int_identity( 

( 

the.interval . elapsed.houra 

* 

hours.to.Beconda ) ) ) 

+ 

Int_identity( 

( 

the.interval . ©lapsed.minutes 

♦ 

mi nut es.to. seconds ) ) ) 

+ 

Int_identity(the_interval.elapsed_seconds)) , 1)) 

AID 

ffood_interval(the_interval) ) 

AID 

good.durat ion (temp) ) 

AID 

good_second( (the.interval , elapsed.milliseconds/ 1000) ) ) ; 

— ! USE lemma pair.minus II TRAIT fixed.point 

WITH 

( 

( 

( 

( 

( 

Int_identity( 

( 

the.interval . elapsed.days 

* 

days.to.seconds) ) 

+ 

Int_identity( 

( 

the.interval . elapsed.hours 

* 


hours.to.seconds) ) ) 
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+ 

Int_identity( 

( 

tbe.interval . elapsed.minutes 

* 

minutes_to_ seconds) ) ) 

+ 

Int_identity(the_interval.elapsed_8econds)) 

* 

1000) 

+ 

Int_ ident i t y ( the_ int er val . elap 6 ed_milliseconds) ) , 
1000, (the_interval.elapsed_miliiseconds/lOOO) , 1 

FOR 

nl : Int, di: Int, n2:Int, d2:Int 
— ! substituting for left; 

— I USE lemma subtract_duration_ equals II TRAIT 
t i»e_r epres entat ion.convers ions 

VITH 

temp, 

pair( 

( 

( 

( 

( 

( 

Incident ity( 

( 

the.interval . elapsed.days 

* 

days_to_seconds)) 

+ 

Int.identityf 

( 

the_ interval . elapsed_hours 

* 

hours - to_seconds) ) ) 

+ 

Int__identity( 

( 

the_interval . elapsed_minutes 

* 


minutes_to_seconds) ) ) 
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Int_identity(the_int6rval.elapsed_seconds)) 

♦ 

1000) 

+ 

Int.ident ity (the. interval . elapsed_milliseconds ) ) , 
1000), 

pair ( (the_interval . elapsed«jnilliseconds/ 1000) , 1) 

FOR 

m: AnyRecordSort , n : AnyRecordSort , p: AnyRecordSort 
— ! substituting lor left; 

— ! USE lemma seconds_to_duration II TRAIT sort_names 
WITH 

(tbe_ interval . elapsed_milliseconds/ 1000) 

FOR 

the_second: Int 
— ! substituting for left; 

— ! USE axiom good_seconds_to_good_duration II TRAIT 
time_representation_conversion8 

WITH 

(the. interval . elapsed_milliseconds/ 1000) 

FOR 

the^second: Int ; 

— ! USE lemma good_duration_sum II TRAIT 

time_representation_conversions 

WITH 

temp, 

seconds_to_duration( 

(the_interval . elapsed«milliseconds/ 1000) ) 

FOR 

dl : AnyRecordSort , d2: AnyRecordSort ; 

— ! USE axiom Int_identity II TRAIT Z 

WITH 

( 

( 

( 

( 

Incident ity ( 

(the_interval . elapsed_day8*days_to_8econds) ) 
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+ 

Int_identity( 

( 

the. interval * elapsecLhours 

* 

hours _to_ seconds) ) ) 

+ 

Int.identity( 

( 

the_interval . elapsed_ainutes 

♦ 

minutes_to_seconds) ) ) 

+ 

Int_identity(the_interval. elapsed.seconds) ) 

* .... . ~ ' : . . 

1000) FOR n : Int 
— ! substituting for left; 

— ! PRECOHDITIOR = ( 
good_duration( 

seconds_to_duration( ( (the_interval . elapsed milliseconds 

) 

/ 

1000 ))) 

-> 

( (good__duration(temp) 

AID 

good_duration( 

seconds_to_duration( 

( 

(the.interval . elapsed_ailliseconds) 

/ 

1000 )))) 

AID 

( 

good.dur at i on ( ( t emp 
+ 

seconds_to_duration( 

( 

(the_interval . elapsed.milliseconds) 

/ 


1000 )))) 
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(good.interval(the.interval) 

AND 

((temp 

+ 

s econds.to.durat ion ( 

( 

(tlie_ interval . elapsed_milliseconds) 

/ 

1000 ))) 


pair(( 

Int.ident ity ( ( ( ( ( 

Int_identity( 

( ( t he. int erval . elaps ed.day s ) 

* 

days.to. seconds) ) 

+ 

Int_identity( 

( (the. interval . elapsed.hours) 
* 

hours. to. seconds) ) ) 

+ 

Int.identity( 

((the. int erval. elapsed.minutes) 
* 

minutes.to.seconds) ) ) 

+ 

Int.identity( 

(the.interval . elapsed. seconds) ) ) 

* 

1000 )) 


Int_identity( 

(the. interval . elapsed.milliseconds) ) ) , 

1000 )))))); 

temp: =(temp+ 

built in . durat ion.ize ( (the.interval . elapsed.milliseconds/ 

1000 ))); 
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! USE lemma pair.plus II TRAIT fixed_point 
WITH 
( 

( 

( 

Int.identity ( 

(the_ interval . elapsed_days*days.to_seconds) ) 

+ 

Int_identity( 

(the.interval . elapsed.hours+bours.to.seconds) ) ) 

+ 

Int.identity( 

( 

the. interval . elapsed_minutes 

+ 

ainutes.to.seconds) ) ) 

+ 

Incident ity (the.interval . elapsed.seconds)) t 1 f 
interval * elapsed.milliseconds , 1000 

FOR 

nl ; Int , dirlnt, n2:Int, d2:Int 
! substituting for left; 

! USE axiom Int.identity II TRAIT Z 

WITH 

( 

( 

Int.identityf 

(the.interval . elapsed.days+days.to. seconds) ) 

+ 

Int.identity ( 

(the.interval. elapsed_hours*hours.to_seconds)) ) 

+ 

Int.identity ( 

( 

the_ interval . elapsed .minutes 

* 

minutes. to.seconds)) ) 

FOR 
n: Int 

substituting for left; 
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— i USE lemma pair .plus II TRAIT fixed.point 
WITH 

( 

( 

Int_identity( 

(the. interval . elaps ed.days*days.to. seconds ) ) 

+ 

Int.identityC 

(the. interval . elapsed.hours*hourB.to_seconds) ) ) 

+ 

Int_identity( 

( 

the. interval . elaps ed.minutes 

* 

minutes.to.seconds) ) ) , 1, 
the. interval. elapsed.seconds , 1 

FOR 

nl:Int, dl:Int, n2:Int, d2:Int 
— ! substituting lor lelt; 

— * USE axiom Int.identity II TRAIT Z 

WITH 

( 

Int_identity( 

(the.interval . elapsed.days*days_to.seconds) ) 

+ 

Int.identity( 

(the.interval . elaps ed.hours*hours.to_seconds) ) ) 

FOR 

n:Int 

— ! substituting lor lelt; 

— ! USE lemma pair.plus II TRAIT lixed.point 
WITH 
( 

Int_identity( 

(the.interval . elapsed_days*days.to_seconds) ) 

+ 

Int_identity( 

(the.interval . elapsed.hours*hours.to.seconds) ) ) , 
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1, (the, interval . elapsed.minutes*mintttes to.seconds) 
1 

FOR 

nl:Int, di;Int, n2:Int, d2:Int 
— f substituting for left; 

! USE lemma pair.plus II TRAIT fixed_point 


WITH* 

(the^interval . elapsed.daya*days_to_seconds) , i , 
(the.interval.elapsed_houra*hours_to_seconds) , 1 

FOR ^ > 

nlrlnt, dlrlnt, n2:Int f d2:Int 
— ! substituting for left; 

— ! USE axiom seconds_to_milliseconds II TRAIT 
conversion,! actors 
— ! substituting for left; 

” • USE lemma divides.pi II TRAIT fixed.point 
WITH 

the.interval . elapsed.milliseconds , 1 , 
seconds.to_milliseconds FOR n:Int # d:Int, i;Int 
— ! substituting for left; 

! USE lemma seconds.to.duration II TRAIT sort .names 

WITH 

(the, interval . elapsed_days*days.to_seconds) 

FOR 

the, second: Int 
“I substituting for left; 

“ ! USE lemma seconds_to_duration II TRAIT sort,names 
WITH 

(the_interval . elapsed.hours+hours.to.seconds) 

FOR 

the_segond:Int 
-! substituting for left; 

-! USE lemma seconds_to,duration II TRAIT sort .names 
WITH 

(the. interval . elapsed_minutes*minutes_to_seconds) 
FOR 

the_second:Int 
-! substituting for left; 

-! USE lemma seconds.to.duration II TRAIT sort.names 
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WITH tbe.interval. elapsed_seconds FOR the_second:Int 
— ! substituting for left; 

— ! USE lemma seconds.to.duration II TRAIT sort_names 
WITH tbe.interval. elapsed.mill is econds FOR the. second: Int 
— ! substituting for left; 

— ! USE axiom interval.to.duration II TRAIT 
t ime_r epres ent at ion_conv ers ions 
WITH tbe.interval FOR the. interval: AnyRecordSort 
— ! substituting for left; 

— ! SIMPLIFIED PRECOIDITIOI; 

— ! USE axiom good. int erval.to.good.durat ion II TRAIT 

time.representation.conversions 

WITH 

tbe.interval, temp 
FOR 

tbe.interval : AnyRecordSort , the.duration : AnyRecordSort ; 

— ! PRECOIDITIOI = ((temp 

interval.to.duration(tbe.interval)) 

AID 

good.duration(temp)) ; 

RETURI temp; 

EID duration.of; 

FUICTIOI int erval.of (the.duration : II built in. duration) RETURI 
interval 

— I WHERE 

— | GLOBAL seconds.per.day, seconds.per .hour , 

seconds.per.minute : II ; 

— | II good.durat ion (the.duration) ; 

— | RETURI duration.to.interval (the.duration) ; 

— I EID WHERE; 

— ! VC Status: hidden 

— ! □ 


IS 

result : interval; 

the.seconds : built in. duration := the.duration; 

BEGII 

result. elapsed.day8:=duration.utilities. floor ((the.seconds/ 
seconds.per.day)) ; 
the.seconds : = (the.seconds- 

built in. duration_ize( (integer.ize (result . elapsed.days)* 
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seconds.per.day ) ) ) ; 

result . elapsed.hours : =hour.ize(duration_utilities . floor ( ( 
the.seconds/seconds.per.hour) ) ) ; * 

the. seconds : ^(the.seconds- 

builtin . duration. ize ( ( integer. ize (result . elapsed.hours)* 
seconds.per.hour) ) ) ; 

result . elapsed.minutes : =minute_ize(duration_utilities . f loor ( ( 
the.seconds/seconds.per.minute))) ; ' 
the. seconds : =(the. seconds- 

builtin . duration. ize ( (integer_ize(result . elapsed.minutes ) * 
seconds. per. minute) ) ) ; j 

result . elapsed.se conds : = 

second_ize(duration_utilities.floor(the_seconds)); 

the.se conds : =(the_8econds- 
builtin. duration.izefresult . elapsed. seconds)) ; 

! PRECQIDITXGI = (((Int.to.f ixnum(0)<=(the_seconds*1000) ) 

-> - ' .. ' 

(0<=Floor ( (the.seconds* 1000) ) ) ) 

-> 

(good.durationCthe.seconds) 

AID 

(good.durat ion ((the.seconds* 1000) ) 

-> 

( ( (0<=Floor ( (the.seconds* 1000) ) ) 

AID 

(Floor ( (the_seconds*1000) )<1000) ) 

AID 

( (result [. elapsed_milliseconds=> 

Floor ( (the.seconds*1000 ) )] ) 


duration.to.interval(the.duration) ))))); 
! IMSTAITIATE lemma floori II TRAIT fixed.point 
WITH (the.seconds*1000) FOR m: AnyRecordSort ; 
result . elapsed.milliseconds : = 
millisecond.ize( 

duration.utilities . floor ( (the.seconds*1000 ) ) ) ; 
RETURI result; 

EID interval.of; 

EID calendar.utilities; 
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